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PREFACE 



This document provides reference data for the experienced programmer who is familiar with the B 6700/ 
B 7700 Network Definition Language (NDL) and the B 6700/B 7700 Data Communications System. 

This reference manual is divided into the following six chapters and five appendixes. 

• Chapter 1 , INTRODUCTION, describes where the NDL Manual fits into the existing Data 
Communications System documentation, and defines the scope of NDL. 

• Chapter 2, NDL SYNTAX CONVENTIONS, explains the syntactical notation used in defining the 
Network Definition Language. 

• Chapter 3, LANGUAGE COMPONENTS, describes the elements that form the most primitive 
structures of the language. 

• Chapter 4, SOURCE PROGRAM STRUCTURE, describes the basic structure of an NDL program. 

• Chapter 5, DEFINITIONS, describes the various definitions that make up an NDL program. 

• Chapter 6, VARIABLES, describes the program variables available to the NDL programmer. 

• Appendix A, RESERVED WORDS, is a list of "words" that have been set aside for specific 
purposes within the Network Definition Language. 

• Appendix B, TRANSMISSION CODES, provides useful data transmission code tables. 

• Appendix C, SOURCE INPUT FORMAT AND CODING FORM, describes the input format and 
coding form to be used by the programmer. 

• Appendix D, COMPILE-TIME OPTIONS, describes the compiler options available to the user. 

• Appendix E, COMPILER SOURCE AND OBJECT FILES, describes how compiler communication 
is handled through various input and output files. 

The information in the following documents pertains to and supplements the material presented in this 
reference manual: 
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1. INTRODUCTION 



GENERAL 



Thl £ J « h 3 documents concerning the B 6700/B 7700 Data Communications System. 

t 7 T? 1 . . a Communicat ions Functional Description , form no. 5000060, and B 6700 Input/ 
uutput Subsystem Intormation Manual , torm no. SOOOlSS k prerequisite to this docu ment 

SCOPE OF NDL 

Sfv N f^ Defi J i " on f Lanpiaw (NDL) source program describes a data communications network physi- 
cal^ logacally and functional Physical components of a data communications network include the hard- 
ware specifications and capabilities of the various elements which comprise the network. The logica charac- 
teristics of a network are the associations among the various components 1 ^ a data communicaK LSem 
(user, programs, Message Control Systems, etc.), application-oriented characteristics (page sizeTd width 
special-purpose characters, etc.), and the symbolic names used to reference ^hysical^ment?w^in the ' 
network Figure 1-2 illustrates the physical and logical characteristics in their relation to the network ele- 
™ ' f K e ] 'i 11 US o ateS the spnere of influence of a NDL source progranion the logical and physical 
~* SSf-? a f Commun cations System. The area enclosed by the bAen line iTthe "global sphere 
Momation' ™ 68 ^ " l0Cal Sphere of ^fluence." The aVows indicate The flow of 

' . v . ■ ■■ ' ' ■ : : Y .' , . .... ' 

functional behavior of the network or the way in which eac\ data communications 
line is to be^controlled These specifications consist of individual routines, allowingVlie NDL programmer to 
SSSS 1 ^ r t0 H C °r req , Uir ^ t0 mCet thC physical characteristics and apphcatiol Of th7t^fterm 

Ztp^Z ^pf med \ T * 6 r ° Ut f ineS are COmpiled int0 a set of instructions whlh the Dafa Communica- 
tions Processor (DCP) executes to perform the functions described by the NDL program. mmuni ca 

S?Lr r S: Pr0gram k tranSf ° rmedint ° tW0 fi,cs containing the information requi^d to operate the 

a. The Network Information File (NIF), containing the logical and physical specifications of the network. 

USE OF NDL 

Once the data communications hardware has been installed on a B 6700/B 7700 system, several software 

^73^ S 8 ' nenite J? 6 ^ ^^ons network The^SStoted 

SlSS? ' . xu ° ne ° f m °f M ^sage Control Systems (MCS), the Data Comm Controller (DCC) and 
the NDL compiler. The purpose, function, and use of each of these software items are described in the follow- 
^ ing paragraphs. 
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Network 
Elements 


Physical 
Characteristics 


Logical 
Characteristics 


DCPs 


Memory size 

Reconfiguration capabilities 


Set of terminals controlled by each DCP 


LINEs 


Physical location (address) 

Transmission speed 

Type of line and connection 


Station line assignments 
Automatic answer capability 


MODEMs 


Physical delays 
Transmission speed and type 
Continuous vs. controlled carrier 
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Associated Message Control System 


TERMINALS 


Transmission code, speed and type 
Parity 


Transmission numbers 
Special characters 



Figure 1-2. Network Characteristics 
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Message Control System (MCS) 



An MCS is a special purpose DCALGOL program which may be a Burroughs-supplied MCS (SYSTEM/CANDE, 
SYSTEM/ RJE, or SYSTEM/D1AGNOSTICMCS), or a user- written program. The primary function of an 
MCS is, as its name implies, to control the flow of data communications messages between the terminal and 
the main system. Information from the DCP, such as terminal input and status information, is forwarded to 
the MCS via the DCC. Messages from the MCS to the DCP, such as terminal output or network changes, are 
performed by the MCS invoking an intrinsic function called DCWRITE. This intrinsic, as well as the format 
of all MCS and DCP messages, is described in the B 6700/B 7700 DCALGOL Reference Manual , form no. 
5000052. Each station which is defined by the NDL source program must have one, and only one, control- 
ling MCS. 

Data Comm Controller (DCC) 

The DCC is the basic interface between the DCP and the main system. It exists as a subset of the basic 
B 6700/B 7700 Master Control Program (MCP) and operates as an independent task or stack, one such task 
for each active DCP. 

Before a defined data communications network may be utilized, the DCPs which comprise the network must 
be initialized. As each DCP is initialized, the portion of the NDL-defined network which utilizes that DCP 
becomes active. 

Once initialized, each DCC stack transfers messages between the associated DCP and the proper MCS. 




NDL Compiler 



Whereas the DCC and an MCS are required to operate a data communications network, the NDL compiler 
is used to generate the tables and DCP code which, to a large extent, control the way in which the network 
functions. 

The NDL source program, then, must supply the NDL compiler with information which will allow the com- 
piler to produce the proper NIF and DCPCODE files to operate all of the Data Comm Processors and their 
sub-components within the network. (In figure 1-3, the shaded areas indicate the areas of the data communi- 
cations subsystem which are influenced by the NDL source program.) Although an NDL program may con- 
tain up to 1 1 discrete sections, it functionally consists of two interdependent pieces of information: the 
network description and the DCP programs. 

NETWORK DESCRIPTION 

The NDL programmer uses various sections of the NDL source program to describe the logical and physical 
characteristics of the network. The information supplied in those sections is used ^ in part, to supply the DCC 
with the proper tables and DCP code that are used to operate the network. 

The NDL compiler performs consistency checks across the various definitions to ensure that the defined 
network is logically structured. For example, a line must not be associated with a particular modem if the 
defined speed range and transmission type of the modem do not permit a proper interface to the line. Simil- 
arly, a terminal defined to operate in an asynchronous mode must not be associated with a line which uses a 
synchronous adapter. 

All of the information supplied by the NDL definitions is recorded within the NIF file. This enables an MCS 
or user program to gain access to many of the logical characteristics of the network, as well as permitting 
dynamic reconfiguration of the network by an MCS. 
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These definitions are also used to modify or include special areas of DCP code which are network dependent. 
For example, the DCP code for transmitting or receiving characters on a synchronous line is different from 
such code for transmitting or receiving on an asynchronous line. In addition, if any dial-out type lines are 
defined within the network, extra code must be generated for performing dial-out functions. Thus, the NDL 
compiler "tailors" the resultant DCPCODE file to fit all the requirements of the defined network. 

DCP PROGRAMS 

Once a data communications network is logically and physically defined, the functional operation of each 
line and station within the network must be described. These descriptions, called CONTROL definitions 
and REQUEST definitions, are individual programs which are executed by the DCP when required to perform 
the necessary line discipline. Each line must have one associated CONTROL definition, and each terminal 
may have one or more associated REQUEST definitions. 

The CONTROL and REQUEST definitions consist of NDL statements which the compiler transforms into 
the DCP instructions to be executed when performing a particular network function. A RECEIVE REQUEST 
definition is invoked when input from a terminal is to be processed, and a TRANSMIT REQUEST definition 
is executed when output to a terminal has been requested by an MCS or user program. The line CONTROL 
definition is utilized to determine when and for which of the stations on the line a REQUEST definition is 
to be executed. 

Since an NDL source program must handle many lines, the DCP must share its processing capabilities among 
the lines it services. Due to the fact that the data communications subsystem operates in a real-time environ- 
ment, few network functions, if any, require the dedicated use of the DCP for an extended length of time. 
A RECEIVE REQUEST, for example, usually spends most of the time waiting for a character to be sent from 
a terminal. Likewise, a TRANSMIT REQUEST can only operate as fast as the line speed pprmits. Thus, while 
a REQUEST definition is waiting for an external event, or interrupt, from a line, the DCP is free to continue 
execution of a REQUEST or CONTROL definition for another line. 

The allocation of the DCP for the servicing of its many lines is one of the duties of the basic DCP operating 
system and the CONTROL definitions. Figure 1-4 illustrates the means by which the control of the DCP 
is transferred between the operating system and the CONTROL and REQUEST definitions. 

Line Control 

Each CONTROL definition, or "Line Control Procedure," must perform two functions. First, it must select 
which station on the line is to receive attention next, and second, it must decide what particular function is 
to be performed for that station. If the function to be performed is an output request, control is transferred 
to the TRANSMIT REQUEST for the station. If the function is an input operation, the station's RECEIVE 
REQUEST is executed. Network functions which do not involve the reception or transmission of messages, 
such as status or network changes, are performed by invoking a common subprogram, or macro, within the 
DCP operating system itself. 

Request Definitions 

For each type of terminal which is capable of output, a TRANSMIT REQUEST must be named within the 
terminal definition. Likewise, if a terminal h^s input capabilities, a RECEIVE REQUEST must be supplied 
and named. Typically, many stations may share the same REQUEST definitions, just as many lines may 
utilize the same CONTROL definition. In some cases, more than one set of REQUEST definitions may be 
desired, and defined, for a station. 
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Figure 1-4. Transfer of Control Within the DCP 

The functions of a REQUEST definition may be as simple or as complex as the application of the station 
dictates. One of the basic design goals of the DCP is to free the main system from the burden of performing 
basic terminal receptions and transmissions. However, by the proper application and coding of the CONTROL 
and REQUEST statements in NDL, a significant amount of intelligent message processing may be performed 
by the DCP, thereby allowing more of the main system's resources to be free to perform other work. 

The NDL programmer must keep in mind, however, that the DCP runs at a finite rate, and that it is 
operating in real-time. Thus, if too much time is spent processing a message, other lines may fail to be 
serviced quickly enough to avoid transmission errors. Several NDL statements are provided to "break up" 
long strings of NDL code to ensure that the DCP may properly service all of its lines. 

When a REQUEST definition has terminated the processing of an input or output function, it usually branches 
back to the beginning of the CONTROL definition. The CONTROL definition then selects the next station 
to be serviced and the process continues. 

Thus, the functioning DCP can be visualized as a small multiprogramming system, where each line has its own 
program and operating environment and runs asynchronously and independently of the other lines. The 
CONTROL definition and its associated REQUEST definitions form the "main program'* for each line, and 
the common DCP macros are "sub-programs." 



DCP INTERACTION WITH THE MAIN SYSTEM 



Although the DCP is a self-contained and asynchronous device with respect to the main system, it is not an 
autonomous unit, and requires the active participation of the main system and its resources to properly func- 
tion. In particular, main memory storage space is required to contain tables and messages. In addition, the 
DCP requires the allocation of a pool of message areas in main memory for the gathering of input from term- 
inals and reporting of error conditions. 



DCP Tables 

The NDL compiler constructs a series of tables which reflect the physical and logical characteristics of the 
network as defined by the NDL source program. The DCP uses these tables for the storage of status informa 
tion, and for determining what types of functions are to be performed for each of the many different lines 
W and stations which the DCP controls. 

The compiler places a disk image of these tables within the DCPCODE file along with the DCP code itself. 
When the DCP is initialized, the tables are loaded into main memory by the DCC, which also provides the 
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DCP with a reference to the tables. If several DCPs exist which share hardware-exchanged adapter clusters, 
two DCPs may utilize the same set of tables if the network description indicates this mode of operation. In 
the case where a DCP is not "exchanged" in this manner, each DCP uses its own unique set of tables. 

Each set of tables can be divided into two sets of information. Each line has a table, and each station has a 
table. The DCP uses a "line descriptor" to reference each line table. The descriptors for all lines controlled 
by the DCP are stored within a vector, which is then indexed by the physical line adapter address. Each line 
descriptor contains information concerning the status of the line (not ready, connected, busy, etc.), physical 
characteristics of the line (dial-out, switched, etc.), logical characteristics (automatic answer, etc.), and a 
reference to the CONTROL definition which is used for the line. In addition, the line descriptor contains 
the memory address of the actual line table. 

Each line table contains additional information describing the logical and physical characteristics of the line. 
Much of the information in the line table can be referenced and/or modified directly by the NDL CONTROL 
and REQUEST definitions. Other information is reserved for use by the DCP operating system. 

Immediately following the line information in the line table is a vector of station descriptors, one such 
descriptor for each station which can exist on the line. Similar to the line descriptor, each station descriptor 
addresses a table of information for a particular station. The DCP references the proper station table by 
indexing into the line table by the proper relative station address, or "station index," and using the addressed 
station descriptor to reference the proper station table. When a line CONTROL Procedure "selects" a station 
for the purposes of initiating a REQUEST definition, it is actually selecting the proper station table for use. 
Just as the line table contains a reference to the proper CONTROL definition to execute, the station table 
contains references to the appropriate TRANSMIT and RECEIVE REQUEST definitions. It should now be 
apparent that each station assigned to a particular line must utilize the same Line Control Procedure, since 
the stations on the line all share a common line descriptor and line table. However, each station may have a 
different set of REQUEST definitions, since these routines are station oriented. 

Although each station table is of a fixed size, the line tables will vary in size directly proportional to the 
number of stations which can potentially exist on the line. The NDL source program specifically defines 
the maximum number of stations for each line, as well as which stations are assigned to what line. Not all 
station descriptors may be utilized for a given line, i.e., the number of real stations on a line at any given 
moment may be less than the true capacity of the line. A line may be declared with such "holes" when the 
NDL program is compiled, or a line may be reconfigured into such a state by an MCS. In some cases, a line 
may exist with no stations at all. At no time, however, may more stations be assigned to a line than the max- 
imum number defined by the NDL program. Thus, it is the requirement of the DCP operating system and/or 
the CONTROL definitions to ensure that a selected station actually exists, or is valid, as defined by the cur- 
rent state of the network. 

Just as a line may have no valid stations, it is possible and often desirable to define "spare" stations which 
have no line assignment. Such stations cannot be referenced or utilized by the DCP until they are logically 
assigned to a line by a reconfiguration request. Again, any such reconfiguration request will be disallowed 
by the DCC if the characteristics of the station conflict with those of the line to which it is being assigned, 
or with the stations which already exist on that line. Also, since the size of the line table cannot be altered, 
there must exist a "hole" or unused position on the line for the station. 

Alternatively, an existing station may be subtracted from a line, thereby leaving a "hole," and either left 
in limbo with no line assignment, or moved to fill an existing "hole" on another line. Thus, stations which 
have special characteristics for a particular application may be logically moved about within the network 
while the data communications system is operating and without the further use of the NDL compiler. 



DCP MESSAGE MAINTENANCE 



With one exception, all functions performed by the DCP are the direct result of a DCP request message being 
sent to the DCP, usually by an MCS. in the case of terminal output, for example* a "write request" is sent 
to the DCP, which then invokes the action described within the request message itself by means of the. appro- 
priate station's TRANSMIT REQUEST definition. If spontaneous input from a terminal is to be received, 
there is normally no MCS request message associated with the input operation. When a station operates in 
this mode, the terminal is described as being "enabled for input," or simply, "enabled." 

The process of gathering "enabled input messages," i.e., spontaneous input messages, is controlled by the 
CONTROL definition, and, of course, by the RECEIVE REQUEST defined for the terminal. In addition, 
the "enabled" state of a station is initially defined for each station, and may be dynamically changed by the 
controlling MCS. 

When a station is enabled, and the RECEIVE REQUEST is invoked, the DCP must then acquire a message 
area in main memory in which to store the received message text. Such an area, which is called an "enable 
input space," is obtained by a DCP macro called GETSPACE. Since the DCP cannot directly participate in 
the main system memory management functions, a pool of such "enable input" spaces is maintained by the 
DCC. This pool of messages, sometimes referred to as the "available space pool," consists of a set of queues, 
each of which contains a linked list of available message areas of the same size. The NDL compiler computes 
the size of the enable input space required for each terminal based on the defined WIDTH, MAXINPUT, and 
BUFFERSIZE statements within the terminal definition. All terminals of a given size are assigned the use of 
the same queue, in order to reduce the number of different queues required, the NDL compiler rounds each 
terminal's input size up to a multiple of 16 words. 

The available space areas are used for several purposes other than terminal enabled input. Error messages 
from the DCP and "switched line status" result messages are also spontaneous in nature and require an enable 
input space. In addition, it is possible for an NDL Request definition to invoke the GETSPACE macro and 
simply store the contents of variables in the obtained message space in order to communicate with the con- 
trolling MCS. 

When the DCP GETSPACE macro is invoked, an area which is greater than or equal to the required message 
size is delinked from a message queue and assigned to the station. If no suitably sized areas exist within the 
space pool, a "no space" condition results, and the RECEIVE REQUEST must abort reception of input. 

The number of messages assigned to each queue is initially defined by the NDL compiler. By default, two 
areas are assigned to each size queue, although the NDL program may specify an alternate allotment on a 
terminal by terminal basis. 

The DCC has the responsibility of maintaining the available space pool so that GETSPACE may always ob- 
tain a message area. As each available space area is returned to the DCC by the DCP in the normal course of 
completing an input operation, the queue from which the area was obtained is restored so that it contains 
the same number of areas as defined by the NDL compiler. Circumstances may arise, however, where all of 
the areas within a queue have been exhausted, but none of the areas has yet been returned to the DCC so that 
the queue can be replenished. In such an event, the DCP sets a global u space alarm" flag which is sensed by 
the DCC and causes it to immediately examine and replenish all of the available space queues. In addition, 
the DCC will then increase the target number of messages in each totally depleted queue, in order to reduce 
the possibility of future space alarms. During extended periods of DCP inactivity, the DCC will attempt to 
reduce the number of messages in each queue down toward the originally defined target value. 



The DCC attempts to maintain the available space pool within the constraints specified by the NDL compiler 
However, some networks may require more than the default number of message areas for some terminals " 
if too many no space conditions occur. In such an event, the NDL program should specify a larger number 
of message areas for the affected terminals. Since the behavior of a network is difficult to predict under all 
circumstances, the NDL programmer will have to directly observe the effects of different message space spec- 
ifications, and adjust the specifications so that the network operates efficiently without requiring excessive 
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2. NDL SYNTAX CONVENTIONS 



SYNTAX CONVENTIONS 

The syntax diagram is the method used to depict the Network Definition Language syntax. This method 
affords a very concise and lucid exposition of syntax, including defaults, alternatives, and iterations; it is 
rigorous without being cumbersome. There are few formal rules to remember: the basic rule is that any 
path traced along the forward directions of the arrows produces a syntactically valid command. The 
following examples illustrate the technique: 



-^►ROW-V»» 



THE- 
Lfr-YOUR • 



^BOAT-i 1 

rJ U. gently -J 



*-DOWN-r*»- 



r*» STREAM. 



THE-^OLD 



t 



X 



MILL 



Valid constructs from this syntax diagram include: 
ROW THE BOAT DOWN-STREAM. 

ROW, ROW, ROW YOUR BOAT GENTLY DOWN THE STREAM. 
ROW, ROW, ROW, ROW THE BOAT DOWN THE OLD STREAM. 
ROW YOUR BOAT DOWN THE OLD, MILL STREAM. 
ROW THE BOAT DOWN THE OLD, MILL STREAM. 

The following convention is used to control iterations of options or constructs: 



ACROSS THE- 



£ 



•BIG 



-►WIDE 



■MUDDY 



MISSOURI 



The "bridge" over the "2" can be crossed a maximum of two times, so a maximum of two commas (and 
three adjectives) can appear. Valid productions include: 

ACROSS THE BIG MISSOURI 
ACROSS THE BIG, WIDE MISSOURI 
ACROSS THE BIG, WIDE, MUDDY MISSOURI 

From the above example, it should be noted that the number of iterations is controlled by the "number" 
in the feed-back loop. When the "number" is not shown, there is no limit to the iterations. For example, 
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ACROSS THE 



-e»BIG- 



-e» MISSOURI 



♦ WIDE- 



MUDDY 



would include the following valid combinations: 

ACROSS THE BIG BIG WIDE WIDE MISSOURI 
ACROSS THE BIG MISSOURI 

ACROSS THE MUDDY MUDDY MUDDY MUDDY MISSOURI 

If a comma were included in the above example, valid combinations would be as follows: 

ACROSS THE BIG, BIG, MUDDY MISSOURI 
ACROSS THE BIG, WIDE, WIDE, MUDDY MISSOURI 

Key Words 

Boldface symbols and uppercase letters in syntax diagrams indicate symbols and words which appear 
literally in the instruction. 

Syntactic Variables 

In the syntax diagrams, left and right broken brackets (( >) are used to contain syntactic variables that 
represent information to be supplied by the programmer. A particular variable may represent a single 
character, a simple construct (such as an integer or text string), or a relatively complicated construct. 

The following is an example of a syntactic variable that appears in a syntax diagram. 
DEFAULT *»» = — ( default line identifier) : — — ■ — • 



Braces ( { \ ) are used to enclose syntactic variable expressions defined by the meaning of the English 
language expression contained within the braces. For example, the following syntactic variable expression 

ADAPTER — = { (integer} value of 1 thru 8 \ ■ — — 



would include the following valid constructs: 

ADAPTER =1. 
ADAPTER = 6. 
ADAPTER = 8. 

Construct Terminator 

Most constructs in the Network Definition Language must be terminated by a period (.). This is illustrated 

in the syntax diagrams as follows: , W 



The period is part of the syntax and must appear following the construct. 
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"vlg J 



tZ^ZioZ-^ d0 not require a tettninator ' and can be foUowed * 



construct. This is 



The vertical bar ( | ) is not part of the syntax, but merely indicates the termination of the 



construct. 
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3. LANGUAGE COMPONENTS 

LANGUAGE COMPONENTS 
Syntax 

1 ■ — (bit number) — — — — — — j— 

(pit variable) — — 

— • »» (2>>>fe variable) — — — »* 

— — (character) — — a* 

-^(identifier) — b» 

(integer) — — — — — 

-+»(label) — ► 

— (NDL program unit)* — — ■ 

—m» (remark) — — — — — — 

— **> (reserved word)- — : — 

— (space) — — — — — — ► 

— : ► (string) — : — ► 

— — : (system identifier) — ► 

(tally number) - — — — ► 

— (time) — — — - — 

► (toggle number) — — — ► 

Examples 
A 

450 

6110 

IF 

"B6700" 

SYSTEM/CANDE 
30 MILLI 

Semantics 

(bit variable) s f (bit number) s, and (byte variable) s are all described in chapter 6. 

A complete list of the (reserved word)s is contained in appendix A. 

(NDL program unit) is described in chapter 4. 

All other (language components are described in this chapter. 
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CHARACTER 
Syntax 



(digit)— 

■ (hexadecimal character)- 

■ (letter) 



• (single character) ■ 



Examples 

O 

Q 
A 

"Z" 
Semantics 

In all instances, a (character) is an entity whose exact form depends on the context of its usage The 
normal inference is that of an 8-bit EBCDIC character. 

(letter) s and (digit) s are usually used to create (identifier) s md (string) s. 

Wherever (single character] > occurs in the NDL syntax, an 8-bit character is needed. It is unique in that it 
may be formed using two (hexadecimal characters . 
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CHARACTER 

DIGIT 
Syntax 

| one of the EBCDIC characters, through 9, inclusive} _ ^ 

Examples 


5 
9 

Semantics 

Whenever the item of (digit) appears in the NDL syntax, one of the 10 numeric EBCDIC characters from 
through 9 is required. 
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CHARACTER 
(hexadecimal character) 



HEXADECIMAL CHARACTER 
Syntax 



-(digit) 



-*» A 
-»> B 
-*-C 
-*» D 

-*»F 



Examples 



5 

9 

A 

C 

F 

Semantics 

(hexadecimal character) s are defined as consisting of the characters in the decimal digit set plus the char- 
acters A, B, C, D, E, F. (hexadecimal characters are generally used to define program values in terms of 
the hexadecimal (radix 16) number system, where A is equivalent to 10 in the decimal system, B is equival- 
ent to 1 1 in the decimal system, etc. 
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CHARACTER-' 

(tetter) 

LETTER 
Syntax 

|one of the EBCDIC characters, A through Z, inclusive} : "" 1 V ■ - 1 r v ; •, ■ ' — • • ; — #»j 
Examples 

A ' 

Q 
z 

Semantics 

Whenever the item of (letter) appears in the NDL syntax, one of the 26 alphabetic EBCDIC characters 
from A through Z is required. 



Language Components 
CHARACTER 
(single character) 



SINGLE CHARACTER 
Syntax 

any EBCDIC character except the quote Oj~ — — - — 

I 4" -^(hexadecimal character) -^(hexadecimal character) 

Examples 

"A" 
4"FF" 

Semantics 

The primary purpose of having a syntactical item of (single character) in NDL is for use in those places of 
syntax requiring an 8-bit character, which can be any combination of bits from "all off through "all on." 

For ease of programming and recognition of usage, the NDL programmer may use either normal EBCDIC 
graphic characters or (hexadecimal characters to create the needed bit pattern. 
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IDENTIFIER 
Syntax 



(letter)- 



46^- 



( letter)- 
(digit)- 



I 



Examples 
A 

QV 
X3 

B6700 
M5NIMIZER 

Semantics 

(identifier) s have no intrinsic meaning. They are used to give symbolic names to various definitions in 
NDL. 

An (identifier) must start with a {letter) , which can be followed by any combiniatioh of (letter s and 
(digit)s. 



The maximum length of an (identifier) is 17 characters. 



Language Componen ts 
INTEGER 



INTEGER 
Syntax 




Examples 



37 

511 

12345678901 
Semantics 

An (integer) is a positive whole number; i.e., fractions or fractional parts, exponents, etc. are not allowed. 
The maximum (integer) allowed is 99999999999. 



Language Components 
LABEL 



LABEL 
Syntax 

(integer) ■ 

Examples 





22 

123 

99999999999 



Semantics 

definMon) ^ indiCate Where " execution branch" within a given (control ' definition) or {re^es/ 

(label)s are "local" in scope; that is, each (label) must be unique only within a given (control definitions 
or {request definition). For example, the (label) 22 could appear more than once in an NDL program so 
long as it does not appear more than once in the same (control definition) or (request definition) 
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REMARK 
Syntax 

% {EBCDIC characters ( — — - — — - — — — — — 

Example 

% THIS IS A REMARK 
Semantics 

(remark)s can appear anywhere in the source program. When the compiler encounters the percent sign 
(%), it skips immediately to the next source record before continuing the compilation process. 
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SPACE 
Syntax 

— EBCDIC graphic space, hexadecimal 40 1 — — ■ — ■- ■ . — ■ : , , • ' ■ • \ 

Semantics 

The NDL compiler looks at a contiguous sequence of (space) s in a source program as a single (space) 
(except when contained in a (string) ). Therefore, wherever a single space is allowed, the programmer dan 
use multiple (space) s to improve readability of the program. 



Language Components 
STRING 



STRING 
Syntax 



► {any EBCDIC character except the quote (") } 



(hexadecimal character) (hexadecimal character 



) ' 1 » ' 



Examples 

"THIS IS A STRING" 
"AND" "SO" "IS" ♦THIS" 
"AND SO" 4"C9E2" "THIS" 
4"C2F6F7F0F0" 
"%*+?/@ (BIG B)" 

Semantics 

Only (hexadecimal character) (4-bit) and EBCDIC character (8-bit) (string) s can be constructed. 
EBCDIC character (string) s are restricted in that they cannot contain the quote (") character. 
The maximum allowed length of a (string) is 128 8-bit characters (1024 bits). 
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SYSTEM IDENTIFIER 
Syntax 



J \4^- (identifier) - 



Examples 



A 

B6700 
SITE/MGS 

SYSTEM/RJE/DOWNTOWN 

X/Y/ZEBRA 



Semantics 

(system identifiers have no intrinsic meaning. They are used to give symbolic names to various definitions 
£1* * f" tem f entl M 18 dl «erent from an {identifier) in that itis usually used to reference items 
belonging to the system and not simply to the NDL program. 

A maximum of 14 (identifiers, each separated by a slash (/), is allowed. 



Language Components 
TALLY NUMBER 



^^^^^ 



TALLY NUMBER 
Syntax 



Examples 


1 

2 

Semantics 

{tally number} is required to designate one of the three (byte variable) TALLYs; for example, 
TALLY (0) . 
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TIME 



TIME 
Syntax 



•(integer) 



-••-MIN- 
-•►SEC- 



MILLI 



-B- MICRO 



Examples 


5MIN 
30 SEC 
200 MILLI 
9 MICRO 

Semantics 

{time) is used to express or define an increment of time. MIN denotes minutes, SEC denotes seconds, 
MILLI denotes milliseconds, and MICRO denotes microseconds. 

The maximum amount of time that can be specified is 6 minutes 42 seconds. 
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TOGGLE NUMBER 

TOGGLE NUMBER 
Syntax 



-0 



m»l _ — ► 


w~- ^ — 
— *> 




— A — 


— — — — *-5 — 




— ««-6 — — 


_ ; ^. 


; +.7 — 


; 

; S- 



Examples 


4 
7 

Semantics 

(fogg/e number) is required to designate one of the eight (bit variable) TOGs. For example, TOG[5] . 
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4. SOURCE PROGRAM STRUCTURE 



NDL PROGRAM UNIT 
Syntax 



I 



■(constant definition). 
. (MCS definition ) — 



'(translatetable definition > 



» (control definition) • 
(request definition) - 



(modem definition ) • 



-r® 




(terminal definition) -LL-m. (station definition) ■ I t » (line definition) 



(?)- — t— ^ (DCP definition) 



(file definition) 



<£> 
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Continued 



Examples 

CONSTANT . . . 
MCS . . . 

TRANSLATETABLE . . 
CONTROL . . . 
REQUEST . . . 
MODEM . . . 
TERMINAL . . . 
STATION . . . 
LINE ... 
DCP . . . 
FILE ... 

Semantics 



The NDL source program is divided into 1 1 program sections ordered as shown. An NDL program 
must include the control and request sections (in any order), and the terminal, station, line, and DCP 
sections. Each section is described in detail in chapter 5 of this manual. 
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DEFINITIONS 



The NDL definitions which comprise the 1 1 program sections of the source program structure shown in 
Section 4, are listed in alphabetical order and described in the same order: 



a. 


CONSTANT 


b. 


CONTROL 


c. 


DCP 


d. 


FILE 


e. 


LINE 


f. 


MCS 


g. 


MODEM 


h. 


REQUEST 


i. 


STATION 


j- 


TERMINAL 


k. 


TRANSLATETABLE 



Definitions 
CONSTANT 



CONSTANT DEFINITION 
Syntax 



CONSTANT 



Examples 



-{constant identifier )- 



■ ( constant identifier )• 
( string > — . 



CONSTANT 
CONSTANT 
CONSTANT 



NUL = 4""00". 

SOH = 4**01", STX = 4"02". 

CI = SOH 4"00" STX, C2 = "1 23"4"F4* 



Semantics 



The (constant definition) equates each of one or more (identifiers with a (string). Once that equation is 
made, any subsequent appearance of the (constant identifier) is syntactically and semantically equivalent 
to the (string). ' M 

If a (constant identifier) appears after the equal sign, it must have been defined previously in the program. 

Supplementary Examples 

Kxamples of Valid (constant definition)s 

Hxample 1 

CONSTANT GREETING = "WELCOME TO B 6700 TIME SHARING ". 
GREETING' ***** "WELCOME TO B 6700 TIME SHARING." to the (constant identifier) 

Example 2 

CONSTANT 

CR = 4"0D'\ % A CARRIAGE RETURN 

LF = 4"25", % A LINE FEED 

CR ANDLF = CR LF, % A CARRIAGE RETURN AND A LINE FEED 
DELETEL1NE = "DELETED" CR LF. % THE STRING "DELETED", 

% A CARRIAGE RETURN, AND 

% A LINE FEED. 

This example references other (constant identifiers^ to define a (constant identifier). (String)s and 
(constant identifiers may be interspersed to define a (constant identifier). 

Examples of Invalid (constant definitions 

Example 1 

CONSTANT BADCNST = 4"1 23". 

The above (constant definition) would cause a syntax error to be generated, because the (string) is not 
properly formed. The length of the (string) must be a multiple of eight bits. ^ ' 



Definitions 
CONSTANT 

Continued 



F.xaniple 2 



CRANDLF = CR LF, % LINE I 
CR = 4**00", % LINE 2 

LF = 4"2S". % LINE 3 



This example would cause a syntax error to be generated, because the (constant identifier) s LF and CR are 
referred to in line 1, but not declared until line 2 and line 3 A (constant identifier) must be declared 
before any reference to that (constant identifier) can be made. 
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CONTROL DEFINITION 
Syntax 

CONTROL (control identifier ) - 



(error switch statement ) • 



\-*~(label)-*»:— ^ 



^(assignment statement) - 

-(break statement)— 

* (code statemen t ) — 



- (compound statement)- 
• (continue statement) — 

> (delay statement ) — 

.(finish statement) 

-(fork statement)— — — 



*(go to statement) - 
(idle statement) - 
► (if statement ) — 



• (increment statement) ■ 

• (initialize statement ) - 
- (initiate statement)— 
> (pause statement) 

• (receive statement) — 

-(shift statement) 

(sum statement) — — 



► (transmit statement ) 

> (wait statement) 



Definitions 
CONTROL 
Continued 



Examples 

CONTROL C ONTENTION: 
INITIATE REQUEST. 
INITIATE EN ABLEINPUT. 
IDLE. 

CONTROL POLL: 

5: IF STATION GTR THEN 
BEGIN 

10: STATION = STATION - 1. 
INITIATE REQUEST. 
INITIATE ENABLEINPUT. 
END. 

ELSE 

BEGIN 

STATION = MAXSTATIONS. 
GOTO 10. 
END. 
GO TO 5. 

Semantics 

A (control definition^ is an algorithm thai, describes, the allocation of the use of a logical line to the 
stations assigned to that line. It is the (control definition) that decides if and when a station's Receive 
Request or Transmit Request 'should be initiated. 

A single (control definition) must control the logical line resource for all of the stations on a half-duplex 
line. In the case of full duplex, one (control definition) must control the primary line ,. and one additional 
(control definition) can be designated to control the auxiliary line. (One (control definition) could be 
designated as the control for both the primary and auxiliary lines. If a (control definition) is not desig- 
nated as the control for an auxiliary line, then a default equivalent to an (idle statement) is used.) The 
programmer, however, cannot directly define a particular (control definition) for a logical line in its 
(line definition). Instead, for each (terminal definition) , a single (control definition) must be defined. 
(Two (control definitions can be named if the (terminal duplex statement) specifies DUPLEX=TRUE.) 
Next, in each (station definition), a (terminal definition) must be defined for the station (by means of 
the (station terminal statement)). Finally, each (station definition) is assigned to a logical line (in the 
(line station statement) of the (line definition)). This last association must be such that each station (i.e., 
(station definition) ) assigned to the logical line references (indirectly through its (terminal definition)) 
the same (control definitions as every other station assigned to the line. 

A (control definition) for a given line can deal only with one station at a time. All statements executed 
apply to and affect only one station assigned to the line. The (control definition) chooses the station 
with which it wishes to deal by setting the value of the (byte variable) STATION to the chosen station's 
station index. 

(control identifier) has the same syntactic form as (identifier). 

The statements in a (control definition) are executed sequentially. In some cases, however, it is desirable 
to alter the order of execution of statements within the procedure. A (control statement) preceded 
by a (label) is one means of accomplishing this. The (go to statement) is used to transfer control to a 
(label)ed (control statement) . 
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ASSIGNMENT STATEMENT 
Syntax 

FORM 1 - LOGICAL ASSIGNMENT 
(assignable bit variable) ~ -»» = - 



" (bit variable) • 
► TRUE 



FORM 2 - VALUE ASSIGNMENT 



FALSE 



(assignable byte variable) 



-(byte variable)- 
^(integer) - 



*~(byte variable) 
o (integer)- 



■(single character)—. 

-(single character) 
-(translate table identifier ) ( byte variable >-»►)• 
- { receive ' 'address ' ' statement } 



Examples 

TOG [0] = TRUE. 
TOG (1) = TOG [OK 
LINE (BUSY) = FALSE. 
RETRY = STATION (TALLY). 
STATION = MAXSTATIONS. 

TALLY [0] = STATION (FREQUENCY)— TALLY [ 1 1 
CHARACTER = TRANSTABLEID (CHARACTER). 
STATION = RECEIVE ADDRESS (TRANSMIT) [ADDERR:999] . 
Semantics 

FORM 1 

™LSo lUSeS ValUe ° n right Side ° f thC equalsign to replace the current value of (assignable 
FORM 2 

hv^SSS\ nt A °H USeS . a ca, f lated va,ue on the of equal sign to be stored in the (assignable 
byte variable). Arithmetic calculations are done in modulo 255 arithmetic. 

(assignable byte variable) = (translatetable identifier) ((byte variable)). 

Jh^ construct is the means to in voke user-defined character translation. User-defined translation is 
effected by three areas of the NDL source program. 

a. In a (translatetable definition) the programmer must define the contents of a translation 
table and associate a (translatetable identifier) with it. 



Definitions 



c. 



CONTROL 
Assignment Statement -Continued 

In the (terminal definition) of a terminal type that requires special character translation 
the programmer should suppress automatic character translation by using either of the 
following torms of (terminal code statement) : 

CODE = BINARY, 
or 

CODE = EBCDIC. 

In a (control definition) or (request definition), the programmer invokes the translation 
by using this option of the value assignment. Any (byte variable) can be designated as 



containing the character to be translated. 

The (trans faetable identifier) identifies the translation table to be used. An (assignable byte variable) 
Sored CqUal Sign ' identifying whe re the resulting translated character is to be 



If N is the (source size) (defined in the (translate table definition)),^ the N low-order bits of the 
(byte variable) are used as an index into the translation table. The eight-bit character thus indexed is 
stored in the (assignable byte variable). 

(assignable byte variable) = (receive "address" statement}. 

This construct attempts to RECEIVE the address characters Of a terminal, . d store in (assignable by te 
variable) the station index of a station whose address characters are equal to those received. The 
\ receive address statement \ is the same as described in the semantics of the RECEIVE ADDRESS 
option ot the (receive statement) . The optional syntax in the {receive "address" statement} invokes 
the same actions as described in the (receive statement) semantics except for ADDERR Any action 
specified lor ADDERR is taken if no valid station assigned to the line is found with address characters 
equal to those received. 



5-7 



Definitions 
CONTROL 
Break Statement 



BREAK STATEMENT 
Syntax 



BREAK ►( 



•j — . -p — ♦NULL i 

J L_W delay time } —J 



-(break time)- 



(delay time)- 



Examples 

BREAK (*,NULL). 

BREAK (200 MILLI, 3 SEC). 

BREAK (*,3SEC). 

BREAK (100 MILLI, NULL). 

Semantics 

The (break statement) causes binary zeros to be transmitted on the line, thus changing the state of the 
line to a "spacing" condition for a specified time. 

(break time) specifies the (time) to break. An asterisk indicates that a standard break of 2 character 
times should be used. 

(delay time) specifies the <rtm?> to delay subsequ^ 
continues. 



Definitions 



CONTROL 

(. ode Statement 



CODE STATEMENT 
Syntax 

CODE ^ = | » ASCII 



BINARY- 



Semantics 



CODE= ASCII invokes the ASCII-to-EBCDIC translation for received data and the EBCDIC-to-ASCII 
translation for transmitted data. 

CODE=BINARY inhibits any character translation on data transmitted or received. 
Pragmatics 

JS^fek statement ) a,lows a Programmer to either invoke or inhibit on a logical line the DCP ASClI-to- 
bBCDIC character code translation for input, and the EBCDIC-to-ASCII character code translation for 
output Any {terminal definitiotb that names, in its \terminal control statement), /a (control definition) 
that utilizes the (code statement), must define ASCII(BINARY) as its character code in the (terminal 
code statement). (Refer to the (terminal code statement) in this chapter.) 

Once that translation has been invoked on a logical line, the translation continues until such time that it is 

!?on df lip - "Atrn 11 " -J^M' trans,ation wil1 be °* that line until invoked again by execu- 

M rnn£ ?I™ ^ is transferred to a (request definition) which executes one of the 

following: CODE=ASCII, TERMINATE NORMAL, TERMINATE LOGICALACK TERMINATF 
LOGICALACK(RETURN), TERMINATE ERROR TERMINA^eS a 
Receive Request) TERMINATE NOINPUT. ' 1 executing a 
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COMPOUND STATEMENT 
Syntax 



~L 



BEGIN 1 ^-(control statement) — I p. £j^ D . ^ # 

Examples 

BEGIN % EXAMPLE 1 

INITIATE TRANSMIT. 

TRANSMIT EOT. 

FINISH TRANSMIT. 

END. 

IF STATION (VALID) THEN 

IF STATION (READY) THEN 

BEGIN % EXAMPLE 2 

INITIATE TRANSMIT. 

TRANSMIT "ON THE AIR". 

FINISH TRANSMIT. 

END. 

Semantics 

The (compound statement) groups several statements together to form a logical sequence. To execute 
more than one statement when the condition of an (if statement) is satisfied, a (compound statement 
must be used. N / 
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CONTINUE STATEMENT 
Syntax 

CONTINUE — 



Semantics 

The {continue statement) can appear in only those (control definition) s and (request definition's 
written to communicate with full duplex terminal types. This statement causes the co-line to resume 
processing, if, and only if, it had been suspended by a (wait statement) or a (receive statement) with a 
CONTINUE option specified. If the co-line had not been suspended, this statement acts as a no-op. The 
(continue statement) has no effect upon the line on which it was executed. 

Pragmatics 

Refer to the (fork statement} pragmatics. 
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DELAY STATEMENT 
Syntax 



DELAY 



*(delay //me)— — — , 



Example 

DELAY (10 MICRO). 
Semantics 

Pragmatics 

K^&t^l^^f^ *" *°- eenice Ouster Attention Needed 



The (tf 
next statement 
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ERROR SWITCH STATEMENT 
Syntax 

ERROR— *• [— »• ( switch number ) — *»-] : 



— / T V *-BUFOVFL- 



- y T^-*-BREAK- 



Definitions 
CONTROL 
Error Switch Statement 



1 ^"LOSSOFCARRIER- 
— / T V *- PARITY 



P^STOPBIT- 




l^*»TIMEOUT- 



■(lahct)- 
»ABORT- 
►NULL " 



Examples 

ERROR [0] = BREAK:0,BUFOVFL:NULL,LOSSOFCARRIER:ABORT 

PARITY :999, STOPBIT:999, TIMEOUT:NULL. 
ERROR [1] = BREAK:NULL. 
ERROR [99] = BUFOVFL:NULL . 

Semantics 

The (error switch statement} is a non-executable statement that allows the programmer to define a 
set of default actions that are to be taken in a (receive statement) if the specified errors occur. 

(switch number) has the syntactic form of (integer). 
BREAK 

The BREAK option variations cause actions as described if a break, that is, at least 2 character-times of 
a spacing line condition, is detected by the adapter cluster while receiving: 



BREAK: NULL 
BREAK: (label) 

BREAK: ABORT 



causes no action. Execution proceeds as if the break did not occur, 
sets TRUE the (bit variable) BREAK[RECEIVE] , and branches control 
to (label). 

sets TRUE the (bit variable) BREAK [RECEIVE] , and executes an 
implicit TERMINATE ERROR. 



BUFOVFL 



The BUFOVFL option variations cause actions as described if the DCP is unable to service a cluster 
Attention Needed (CAN) interrupt before the Adapter Cluster receives another character (thus destroying 
the previous character): 



BUFOVFL:NULL 

BUFOVFL: (label) 
BUFOVFL: ABORT 



causes no action. Execution proceeds as if the error condition did not 
occur. 

sets TRUE the (bit variable) BUFOVFL, and branches control to (labe,). 
sets TRUE the (bit variable) BUFOVFL, and executes an implicit 
TERMINATE ERROR. 
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LOSSOFCARRIER 

The LOSSOFCARRIER option variations cause actions as described if a loss of carrier is detected while 
receiving. 

LOSSOFCARRIER:NULL causes no action. Execution proceeds as if the error 

did not occur. 

LOSSOFCARRIER: (label) sets TRUE the (hit variable) LOSSOFCARRIER, and 

branches control to (label) . 
LOSSOFCARRIER: ABORT sets TRUE the (bit variable) LOSSOFCARRIER, and 

executes an implicit TERMINATE ERROR. 

There is one exception to the actions described above. If a loss of carrier is detected while receiving, and 
if the terminal is modem-connect, and if the terminal's (station definition) references a (modern 
definition) that contains the statement LOSSOFCARRIER=DISCONNECT, then an implicit disconnect 
is done, regardless of the action associated with LOSSOFCARRIER in the (error switch statement). 

PARITY 

The PARITY option variations cause actions as described if a parity bit error is detected by the adapter 
cluster: 

PARITY :NULL causes no action. Execution proceeds as if the error did 

not occur. 

PARITY : (label) sets TRUE the (bit variable) PARITY, and branches control 

to (label). 

PARITY: ABORT sets TRUE the (bit variable) PARITY , and executes a 

TERMINATE ERROR. 

STOPBIT 

The STOPBIT option variations cause the described actions if a stop bit error is detected by the adapter 

cluster: 

STOPBIT:NULL causes no action. Execution proceeds as if the error did 

not occur. 

STOPBIT: (label) sets TRUE the < bit variable) STOPBIT , and branches control 

to (label). 

STOPBIT: ABORT sets TRUE the {hit variable) STOPBIT, and executes a 

TERMINATE ERROR. 

TIMEOUT 

The TIMEOUT option variations cause the actions described if the time required to receive a character 
exceeds the (timeout time). The (timeout time) is defined in the (terminal timeout statement). 
but can be overridden by including the ((timeout time)) or (NULL) syntax options in the Receive 
statement). 

TIMEOUT:NULL causes no action. Execution proceeds as if the error did 

not occur. 

TIMEOUT: (label) sets TRUE the {bit variable) TIMEOUT, and branches 

control to (label). 

TIMEOUT: ABORT sets TRUE the (hit variable) TIMEOUT, and executes a 

TERMINATE ERROR. 
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Pragmatics 

An (error switch statement) must be associated with a (receive statement) by means of a (switch number^ 
reference before any of the default actions will be invoked. The (error switch statement) can appear in a 
{control definition) as many times as the programmer deems convenient providing the following 
restriction is observed: Within a given (control definition) , (error switch statements must have a 
unique {switch number), and all (error switch statements must precede all executable statements in the 
procedure. 
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FINISH STATEMENT 
Syntax 



FINISH 



TRANSMIT 



Hfc-NULL 



• ( delay time ) • 



Examples 

FINISH TRANSMIT. 
FINISH TRANSMIT (NULL) 
FINISH TRANSMIT (3 SEC). 

Semantics 

The purpose of the (finish statement) is to take a line out of the transmit ready state and prepare the line 
to receive information. The adapter cluster delays a period of time long enough for the last character 
TRANSMITted to be transmitted, plus 2 milliseconds, before the line is put in a receive ready state. Al- 
though the (finish statement) puts the line in a receive ready state, the cluster hardware invokes a delay 
that inhibits any data from being received for 25 milliseconds. An INITIATE RECEIVE construct should 
precede any subsequent (receive statement) , to override the 25 millisecond hardware delay. 

The (delay time) option allows the programmer to specify a software delay of (time) before execution 
continues in the (control definition). 

For example, the statement 

FINISH TRANSMIT (3 SEC). 

is equivalent to 

FINISH TRANSMIT. 
DELAY (3 SEC). 



The FINISH TRANSMIT (NULL) construct is equivalent to FINISH TRANSMIT. 
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1 >rk Statement 

FORK STATEMENT 
Syntax 

FORK label > 

Example 

FORK 10. 

Semantics 

The (jbrk statement) is. allowed in only those (control definition's and {request definition's that are 
written to communicate with full duplex terminal types. This statement can be executed in the 
(control definition) or (request definition) of the auxiliary line or the primary line. The execution of this 
statement causes the co-line control, if not busy, to branch to and begin executing code in the (control 
definition) that executes the FORK at the (label specified, while control on the FORKing line executes 
an implicit PAUSE (i.e., a (pause statement)) and continues executing in parallel. The co-line is determined 
busy or not busy by testing the BUSY bit (i.e., LfNE(BUSY) or AUX(L1NE(BUSY», whichever is appro- 
priate). If the co-line is busy, the (fork statement) acts as a no-op. 

Pragmatics 

Synchronization problems can occur between the primary and auxiliary lines as a result of the ( fork 
statement ) executing the implicit PAUSE. The implicit PAUSE yields use of the DCP, to allow processing to 
proceed on other lines. Thus, processing on the co-line is actually started before the FORKing line exits 
the (fork statement) . As a result, the programmer must, by some means (e.g., by setting and testing line 
TOGs), effect the synchronization of the lines. This is especially critical if the code contains (wait 
statements and (continue statements. The following example illustrates how full duplex lines could 
"hang" as a result of poor synchronization. 

FORK 10. 
WAIT. 



10: CONTINUE. 
WAIT. 



Assume that the primary line executes the FORK 10. At that point, the primary line temporarily yields 
use of the DCP to other lines. The auxiliary line starts up and executes the CONTINUE. Since primary 
control is still at the (fork statement) and is not in a (wait statement) , the auxiliary line CONTINUE acts 
as a no-op. Next, the auxiliary line executes the WAIT. When the primary line is given use of the pro- 
cessor again, it executes its WAIT. At this point, the primary and auxiliary lines are "hung," each WAITing 
for a CONTINUE from its co-line. 




5-17 



Definitions 
CONTROL 
Go To Statement 



\ 



GO TO STATEMENT 
Syntax 

GO — t 1 1 **> (label > 



TO 



I 



-(byte variable)- 



(label) 



Examples 



GO 10. 
GOTO 10. 

GO TO TOGS, (0, 1,2, 3). 
GO TO STATION (5, 9, 12). 

Semantics 

The (go to statement) alters the path of control, that is, the sequential flow of statement execution, within 

a (control definition). 

GO TO (label) 

This form of the (go to statement) unconditionally transfers control to the (label) specified. 
GO TO (byte variable) ... 

This form of the (go to statement) provides a convenient means of dynamically selecting one or more 
(label)s to which control could branch. The (label) to branch to is selected by using the (byte variable) 
as an index value. If N represents the number of (label)s in the (go to statement), then the (label)s are 
numbered to N-l. The (label) corresponding to the index value is the (label) to which control 
branches. If the index value is greater than N-l , then control continues at the statement following the 
(go to statement). 

Supplementary Example 

GO TO STATION (5, 9, 12). 

% EXECUTION CONTINUES HERE IF STATION > 2. 



5: TOG [Oj = TRUE. 



9: TOG [11= TRUE. 



12: TOG [2] = TRUE. 
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Control 

Go To Statement Continued 



This example illustrates the "GO TO (byte variable) . . .** option of the (go to statement). The value of 
STATION determines the next statement to be executed. If the value of STATION is 0, control branches 
to the (label) v 5; if the value of STATION is 1 , control branches to (label > 9; and if the value of STATION 
is 2» cohtrbi branches to (label} 12. If the value of STATION is greater than 2, control continues at the 
next sequential statement. 



tr. 
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IDLE STATEMENT 
Syntax 

IDLE - — 



Semantics 

The execution of the {idle statement) causes a logical line to be suspended in an idle state. Specifically, 
IDLE causes the LINE(BUSY) (bit variable*) to be set FALSE, the line to be suspended in a "sleeping" and 
"ready" status, and all subsequent inbound data to be discarded. 

Pragmatics A 

W 

The (idle statement) suspends the execution of a (control definition) for a logical line. Normally, this 
statement should be executed only when there are no outbound messages queued for any stations on the 
line and none of the stations on the line are ENABLED for input (or possibly, if the programmer wants any 
available inbound data discarded). Consider the following example of the contention-type (control 
definition) taken from the Burroughs SYMBOL/SOURCENDL program. 

CONTROL CONTENTION: 

INITIATE REQUEST. 
INITIATE ENABLEINPUT. 
IDLE. 

In this example, IDLE is executed oniv alter it has been determined (by means of INITIATE REQUEST 
and INITIATE ENABLEINPUT) that the station is not QUEUED and not ENABLED for input. 

Once a line is in an idle state, the line remains in an idle state until one of the following circumstances 

occurs: 

a. If the line TYPE is DIALIN and the line becomes connected (as a result of ANSWER = TRUE 

in the (line definition) , a DIALOUT (TYPE = 98) DCWRITE from the MCS, or an ANSWER THE 
PHON E (TYPE = 1 00) DCWRITE from the MCS), the (control definition) is initiated for the 
line. 

b. If any of the following station-oriented DCWRITEs are executed for any station assigned to the 
line, then the (control definition) is initiated for the line. 

1. ENABLE INPUT (TYPE = 35) 

2. DISABLE INPUT (TYPE = 36) 

3. SET CHARACTERS (TYPE = 39) 

4. SET TRANSMISSION NUMBER (TYPE = 40) 

5. SET/RESET LOGIC ALACK (TYPE = 43) 

6. NULL STATION REQUEST (TYPE = 48) 

7. SET/RESET SEQUENCE MODE (TYPE = 49) 

c. If a WRITE request or a READ request is found in the DCP's Request Queue (placed there as a 
result of the MCS executing a WRITE (TYPE = 33) DCWRITE or a READ-ONCE ONLY 
(TYPE = 34) DCWRITE, or the I/O intrinsics) for a station on the line, then the appropriate 
{request definition) is initiated for the line. 



IF STATEMENT 
Syntax 
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IF 



•-FALSE- 



-TRUE 



+»(bit variable)-** 
(byte variable^— 
(integer} 



^(single character)-* 



-►LSS - 
■**LEQ- 
-**EQL- 
-►NEQ- 
-«*-GEQ- 
■►GTR- 



-(byte variable) - 
"■(integer) — 



-* (single character)-** 



-THEN 



-^(control statement)^ 



ELSE -^(con trol state 



?ment)~* 



Examples 

IF TRUE THEN. 

IFTOGfO] THEN TOG[0] = FALSE. 

IFTALLYfO] LSS TALLYfl] THEN TALLYfO] = TALLY[1]. 

IF CHARACTER = 4"FF" THEN 
INITIATE BREAK. 

ELSE 

BEGIN 

CHARACTER = 4"00". 
GO TOO. 

IF STATION ( READY ) THEN 

IF STATION(QUEUED) THEN 
LINE (TOG[0] ) = TRUE. 
ELSE 

GOTO 10. 
ELSE IDLE. 
Semantics 

The {if statement) causes a condition (i.e., a Boolean expression) to be evaluated. The subsequent path of 
program control depends on whether the condition is evaluated as TRUE or FALSE. 

If the condition is TRUE, the (control statement) following the THEN, if present, is executed. Program 
control then resumes at a statement that follows the (if statement) . 

If the condition is FALSE, the (control statement) following the ELSE is executed or, if the ELSE 
(!f"memem) en ^ * ° mitted ' program contro1 resumes at the (control statement) following the 
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The (control statement) can be any legal (control statement} * including the (if statement) and 
(compound statement) . The meanings of the relational operators are contained in table 5-1 . The follow- 
ing diagrams illustrate the (if statement) semantics. 

j TRUE ^ p-j 

IF {condition } THEN (control statement) (control statement) 
FALSE ^ 

TRUE-j | : j 

IF { condition [ THEN (control statement) ELSE (control statement) (control statement) 
FALSE ^ ' — J 



Table 5-1. Relational Operators 



RELATIONAL OPERATOR 


MEANING 


SYNONYMS 


LSS 


Less than 


<and LS 


LEQ 


Less than or equal to 


LE 


KQL 


Equal to 


= and EQ 


NEQ 


Not equal to 


NE 


GEQ 


Greater than or equal to 


GE 


GTR 


Greater than 


>andGT 
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INCREMENT STATEMENT 



Syntax 



INCREMENT 



♦-SEQUENCE 




-NULL 



L-^SEQERR 



Examples 



INCREMENT SEQUENCE. 
INCREMENT SEQUENCE [SEQERR: NULL]. 
INCREMENT SEQUENCE [NULL) . 
INCREMENT SEQUENCE [999] . 



Semantics 



The (increment statement) causes the sequence number stored in the DCP Station Table to be increased by 
the value of the increment (also stored in the DCP Station Table), providing that the station is in sequence 
mode; otherwise, this statement is a noTop. 

When using the INCREMENT SEQUENCE construct, provision should be made for taking action if the 
increment caused the sequence number to exceed (overflow) the size of the sequence number field. The 
programmer can take such action by including the optional syntax. Failure to include overflow action 
results in an implicit TERMINATE ERROR if an overflow occurs. 

The SEQERR :NULL and NULL options are semantical^ equivalent. These options set the SEQERR 
(bit variable) TRUE, and control continues at the next sequential instruction. 

The SEQERR: (label) and (label) options are semanticaly equivalent. They cause the SEQERR (bit 
variable) to be set TRUE, and control to branch to (label\. 

Regardless of whether error action is specified or not, an o\taflow of the sequence number field destroys 
the contents of that field. \ 

Pragmatics \ 

SEQUENCE MODE \ 

A station is considered to be in sequence mode whenever its SEQUENCE (bit variable) toggle is TRUE. 
SEQUENCE can be set TRUE only as a result of the controlling \1CS executing the SET/RESET 
SEQUENCE MODE (TYPE = 49) DCWRITE. In addition, the T\PE 49 DCWRITE also stores the starting 
sequence number and increment in the appropriate fields of the LCP Station Table. 

Sequence mode can be used for any application that the NDL progVmmer may see fit. Its use, however, 
requires common conventions between the NDL programmer and tlV MCS programmer. Burroughs has ' 
utilized sequence mode constructs in two (request definitions of SYMBOL/SOURCENDL- 
READTELETYPE and WRITETELETYPE. Both require the cooperaVon of SYSTEM /C ANDE to effect 
the execution of those statements. The reader is referred to those (reqXest definition) s as an example of a 
particular application that Burroughs has implemented. Other statement relative to sequence mode are the 
(transmit statement) (TRANSMIT SEQUENCE construct) and the (storXstatement) (STORE SEQUENCE 



construct). 
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INITIALIZE STATEMENT 
Syntax 

INITIALIZE 



BCC 
CRC 



1 »» RETRY 

Examples 

INITIALIZE BCC. 
INITIALIZE CRC. 
INITIALIZE RETRY. 

Semantics 

INITIALIZE BCC 

The INITIALIZE BCC construct causes the {byte variable} BCC to be initialized for purposes of 
accumulating a Block Check Character. The value to which BCC is initialized is dependent upon the 
horizontal parity defined for the station's associated germinal definition) (in the (terminal parity 
statement)). If horizontal parity is defined as HORIZONTAL: ODD, then BCC is initialized to all ones 
(i.e., 4"FF"). If defined as HORIZONTAL:EVEN. then INITIALIZE BCC initializes BCC to all zeroes 
(i.c.,4"00"). 

INITIALIZE CRC 

The INITIALIZE CRC construct initializes CRC to the initial value required for calculating the 
Cyclic Redundancy Check. Any germinal definition) referencing a (fontrol definition) (in the (terminal 
control statement) ) that contains this instruction must define the horizontal parity (in the (terminal parity 
statement) ) as HORIZONTAL:CRC(16); otherwise a syntax error is generated. 

INITIALIZE RETRY 

The INITIALIZE RETRY construct causes the value stored in DCP INITIAL RETRY to be stored in DCP 
RETRY. 
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INITIATE STATEMENT 
Syntax 



INITIATE- 



RECEIVE 



-•-TRANSMIT 

/' ■ 

REQUEST— 



•EN^BLEINPISIT 



-NULL- 



• (delay time)- 



-*- BREAK • 



Examples 



INITIATE RECEIVE. / 
INITIATE TRANSMIT (3 SEC). 
INITIATE REQUEST (NULL). 
INITIATE ENABLEINPUT / 
INITIATE BREAK. ' 



Semantics 

INITIATE RECEIVE 



; t'/e 



The INITIATE RECEIVE constat causes t'/e adapter cluster to initiate a receive delay calculated for the 
station. After the delay, the ha/iware is rea/y to receive information 

The amount ol time delayed, i/ierred'to as fhe Initiate Receive delay, is unique to each station and is cal- 
culated at compile-time for e/;lt station. The algorithm that the compiler uses to calculate the Initiate 
Receive delay is described / the following three paragraphs. 

a. If the (modem /iflnition r/ferenced in the (station definition) (in the (station modem statement) 
defines the rn/.em NOISEDfELAY as being greater than zero, then the Initiate Receive delay is 

2 millisecond less than the Combined (time)s defined in the (modem noisedelay statement) and 
the (mode/ transmitdelay statement). 

b. If the n/em NOISEDELAY is defined as zero and the modem TRANSMITDELAY is defined as 
being \f > than 7 milliseconds, then the Initiate Receive delay is zero. 

c. If th/nodem NOISEDELAY is defined as zero and the modem TRANSMITDELAY is defined as 
beh/ equal to or greater than 7 milliseconds, then the Initiate Receive delay is the lesser of 

15 /ilhseconds or ( 1 .5 milliseconds + modem TRANSMITDELAY) 

/ • / : 2 ~ 

The NU/- option or the (delay time) option can be used to override the calculated Initiate Receive delay 
NULL/ 'mediately readies the hardware so that it can receive information, (delay time) specifies a (time) 
to b/j ed in place of the Initiate Receive delay. ' 7 
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Initiate Statement - Continued 

Pragmatics 

An INITIATE RECEIVE instruction should precede the first (receive statement) following a transmission. 
If it does not, there is a possibility that execution of the (receive statement) will be delayed for a period 
of time of up to 25 milliseconds. The cause of the 25-milIisecond delay is described under the semantics 
of the (finish statement) . 

INITIATE TRANSMIT 

The INITIATE TRANSMIT construct causes the Adapter Cluster to be put in a transmit state after a cal- 
culated delay. The amount of time delayed is referred to as the Initiate Transmit Delay, and is unique to 
each station. It is derived by taking the greater of the NOISEDELAY (time) specified for the modem con- 
figured at the system end, or the TURNAROUND (time) specified by the station's associated (terminal 
definition) . This construct must be executed prior to any attempt to transmit information. 

The NULL option or the (delay time ) option can be used to override the calculated Initiate Transmit 
delay. NULL causes the adapter cluster to be put in a transmit state immediately, (delay time) specifies 
a (time) to be used in place of the Initiate Transmit delay. 



INITIATE REQUEST 



The INITIATE REQUEST construct conditionally initiates the next function as indicated by the message 
at the head of the Station Queue. The initiation of the function is conditional, subject to the following: 
the station must be valid, ready, and queued. Specifically, STATfON(VALID), STATION(READY), and 
STATION(QUEUED) must be TRUE ; otherwise, the instruction acts as a no-op. 

The specific function invoked by this construct is dependent upon the type of message at the head of the 
Station Queue. Most commonly the message is a WRITE (TYPE=33) DCWR1TE, thus causing the Transmit 
Request for the station to be entered. A READ-ONCE ONLY (TYPE=34) DCWR1TE message at the head 
of the Station Queue would cause control to enter the Receive Request for the station. Other messages 
(unrelated to input or output) invoke their specific function and then transfer control to the beginning of 
the (control definition) . For example, a SET SEQUENCE MODE (TYPE=49) DCWRITE message wouid 
cause control to enter the subroutine of the DCP that handles setting sequence mode and, when finished, 
control would be transferred to the beginning of the (control definition) . 

The (delay time) option allows the programmer to specify that an implicit (delay statement) for the 
(time) specified, be executed before initiation of the next function from the Station Queue. For example, 
the statement 

INITIATE REQUEST (3 SEC). 



is equivalent to 

IF STATION( VALID) THEN 

IF STATION(READY) THEN 

IF STATION(QUEUED) THEN 
BEGIN 

DELAY(3 SEC). 

INITIATE REQUEST. W 
END. 

The INITIATE REQUEST (NULL) construct is equivalent to INITIATE REQUEST. 
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INITIATE ENABLEINPUT 

The INITIATE EN ABLEINPUT construe! conditionally transfers control to the receive request appropriate 
for the station (that is, the station referenced by the (byte variable) named STATION). The transfer of 
control is conditional, subject to the following: the station must be valid, ready, and enabled for input. 
More specifically, ST ATION( VALID), STATION(RF.ADY), AND STATION(ENABLED), must be TRUE; 
otherwise, the instruction acts as a no-op. 

The NDL programmer can initially enable a station for input by means of the Station enableinput 
statement}. Additionally, after DCP initialization, the station's MCS can enable or disable the station for 
input by means of the TYPES 35 and 36 DCWRITEs. 

(NULL) and ((delay time)) allow the programmer to specify that an implicit (delay statement), for time 
specified, be executed before the transfer of control, (delay time) has the syntactic form of time). For 
example, the statement 

INITIATE ENABLEINPUT (3 SEC), 
is equivalent to: 

IF STATION(VALID) THEN 

IF STATION(READY) THEN 

IF STATION(ENABLED) THEN 
BEGIN 

DELAY (3 SEC). * 

INITIATE ENABLEINPUT. 

END. 

The (NULL) option specifies zero delay. 
INITIATE BREAK 

The INITIATE BREAK construct causes binary zeroes to be transmitted on the line, thus changing the 
state of the line to a "spacing" condition. The line remains in the spacing condition until some subsequent 
construct causes the adapter cluster to change the state of the line. Constructs that would change the 
line's state are INITIATE TRANSMIT, INITIATE RECEIVE, FINISH TRANSMIT, BREAK, and IDLE. 
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PAUSE STATEMENT 
Syntax 

PAUSE : — — • 

Semantics 

The (pause statement) suspends a (control definition) in a "sleep" state for a minimum period of time 
(200 microseconds for the B 6358 Model II DCP, and 6 microseconds for the B 6350 Model I DCP) to allow 
the DCP to service other lines. It is recommended that a (pause statement) be used in any kind of loop 
that would tie up processor time and thereby prevent the servicing of other lines. The failure to do so 
results in a high number of timeout faults. 

Pragmatics 

Instances may occur in which the DCP requires an even greater period of "sleep" to service other lines. 
Repeated timeout faults, despite utilization of the (pause statement) , are indications of such conditions. 
A greater period of "sleep" time can be effected by means of a (delay statement) , with the (time) speci- 
fied greater than "sleep" time effected by the (pause statement) . 



5-28 



Definitions 
CONTROL 

Receive Statement 



RECEIVE STATEMENT 
Syntax 



RECEIVE 



•p NULL p. 

^/miiaml /wirV-J 



ADDRESS 



^(t^KICEIVI 
'1-^ TRANSMIT-' 



BCC - 



♦ CHARAtTER- 

♦ CRC 



n^TRAN — 

-»> ( string) - 



T\«HiRROR fr- 1 »» //< // number) -»-|~ 

^•'.vu/Vr// nmnbvrS 

ADDER R 1-, — j- 

-»»BCCERR : — *J U*»:-^<labch-^ J 

-** BREAK — 



• BUFOVFL - 



CONTINUE 
+~ CONTROL— 
CRCERR — 
END 



FORMATERR - 



LOSSOFCARRIER - 
-^PARITY 



-"-STOPBIT- 



* TIMEOUT - 



-^TRANERR 

^WRU 

(single charactrr} *. 



♦NULL- 
ABORTS 



Examples 

RECEIVE. 

RECEIVE CHARACTER. 

RECEIVE (3 SEC) ADDRESS (RECEIVE) [0, ADDERR:10]. 
RECEIVE (NULL) [ 

PARITY :999, 

LOSS OF CARRIER:999, 

END, 

WRU:NULL 
]. 

RECEIVE CRC [ERROR [1] , CRCERR:! 0] . 
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Semantics 

The (receive statement) causes the adapter cluster to attempt to receive information from the appropriate 
logical line. 

The following two syntax items define a maximum amount of time that the adapter cluster should wait for 
receipt of the first character, and then each subsequent character, if applicable, before assuming that the 
terminal has "timed out." If neither of these options is included, the (timeout time) defined (in the 
(terminal timeout statement}) for the station's (terminal definition) is implicitly used as the (timeout 
time) in this statement. 

(NULL) 

This option specifies that the adapter cluster should wait an infinite amount of time. 
( (timeout time)) 

The (timeout time) defines a (timi) that the adapter cluster should wait for a character. If this (time) is 
exceeded before receipt of a character, and the TIMEOUT syntax appears, then the action specified for 
TIMEOUT is taken (refer to TIMEOUT). If the (timeout time) is exceeded and TIMEOUT syntax does not 
appear, an implicit TERMINATE ERROR is executed. 

The following syntax options define the nature of the information to be received, the amount of informa- 
tion to be received, and how the information is to be handled. If these options are omitted, it is semanti- 
cally equivalent to specifying CHARACTER (i.e., "RECEIVE." is semantically equivalent to "RECEIVE 
CHARACTER.") 

ADDRESS 

The proper number of address characters (as defined by the station's (terminal definition) in the (terminal 
address size statement)) are received and checked for agreement against the actual address characters 
defined in the (station address statement). If the address characters do not correspond, an address error 
condition results . If the ADDERR syntax appears then the specified action is taken; otherwise, an implicit 
TERMINATE ERROR is executed. (Refer to the ADDERR semantics.) 

ADDRESS (RECEIVE) 

This option is equivalent to ADDRESS, except that ADDRESS (RECEIVE) must be used when an address 
pair is defined in the (station address statement) and the programmer needs to check for the proper 
receive address. 

ADDRESS (TRANSMIT) 

This option is equivalent to ADDRESS, except that ADDRESS (TRANSMIT) must be used when an address 
pair is defined in the (station address statement) and the programmer needs to check for the proper 
transmit address. 

BCC 

One character is received and checked against the (byte variable) BCC. If the character received and BCC 
are not equal, a Block Check Character error condition results. If the BCCERR syntax appears, then speci- 
fied action is taken; otherwise an implicit TERMINATE ERROR is executed. 

Presumably, if the RECEIVE BCC instruction appears, the programmer has defined horizontal parity in the 
(terminal parity statement), and the accumulated Block Check Character is contained in BCC. 
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CHARACTER 

One character is received and stored in CHARACTER. 
CRC 

Two characters are received. The first character is checked against CRC[0] , and the second compared 
against CRC[ 1 ] . If the characters received and CRC are not equal, a Cyclic Redundancy Check error 
condition results. If the CRCERR syntax appears, then specified action is taken; otherwise an implicit 
TERMINATE ERROR is executed. 

Presumably, if the RECEIVE CRC construct appears, the programmer has defined horizontal parity 
HORIZONTAL:CRC(16) in the (terminal parity statement) , and the Cyclic Redundancy Check is contained 
inCRC[0] andCRCfl]. 

TRAN 

The proper number of transmission number characters (as defined by the station's associated (terminal 
definition) in the (terminal transmission number length statement)) are received and checked for agree- 
ment with the Receive Transmission Number maintained in the DCP Station Table. If the characters 
received and the Receive Transmission Number are not equal, a transmission number error results. If the 
TRANERR syntax option appears, then specified action is taken; otherwise, an implicit TERMINATE 
ERROR is executed. 

(string) 

The number of characters as indicated by the length of the (string) are received and checked against those 
characters in the (string). If the (string) and the characters received are not equal, then a format error 
condition results. If the FORMATERR syntax option appears, then that action is taken ; otherwise an im- 
plicit TERMINATE ERROR is executed. 

The following syntax options specify actions to be taken upon either the receipt of defined characters or 
occurrences of specific error conditions: 

ERROR[ (switch number)] 

Associates a previously defined Error Switch with the (receive statement) . This allows the programmer to 
associate a set of previously defined error actions with the (receive statement) , thus reducing the amount 
of coding required for each (receive statement) . BREAK, BUFOVFL, LOSSOFCARRIER, PARITY, 
STOPBIT, and TIMEOUT syntax options are not allowed if the ERROR ( (switch number) ] syntax appears 
in the (receive statement) . Refer to the (error switch statement) for more information. 

(switch number) 

Semantically equivalent to ERROR [ (switch number) ] . 
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ADDERR 

The ADDERR option variations cause the following actions if an address error is detected when attempting 
to receive the address characters of a terminal: 

ADDERR sets TRUE the ADDERR (bit variable) and branches control to the next 

sequential statement. 

ADDERR:NULL causes no action. Execution proceeds as if the error condition did not 

occur. 

ADDERR : (label) sets TRUE the ADDERR (bit variable) and branches control to (label) . 

ADDERR: ABORT Not allowed. 

BCCERR 

The BCCERR option variations cause the following actions if the character received is not equal to the 
data stored in BCC. 

BCCERR sets TRUE the (bit variable) BCCERR, and branches control to the next 

sequential statement. 

BCCERR:NULL causes no action. Execution proceeds as if the error condition did not 

occur. 

BCCERR: (label) sets TRUE the (bit variable) BCCERR and branches control to (label). 

BCCERR: ABORT Not allowed. 

BREAK 

The BREAK option variations cause the following actions if a break, that is, at least two character-times 
of a spacing line condition, is detected by the adapter cluster while receiving: 

BREAK sets TRUE the (bit variable) BREAK [RECEIVE] , and branches control 

to the next sequential statement. 

BREAK:NULL causes no action. Execution proceeds as if the break did not occur. 

BREAK: (label) sets TRUE the (bit variable) BREAK [RECEIVE] , and branches control 

to (label). 

BREAK: ABORT sets TRUE the (bit variable) BREAK [ RECEIVE] , and executes an 

implicit TERMINATE ERROR. 
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BUFOVFL 



The BUFOVFL option variations cause the following actions if the DCP is unable to service a Cluster 
Attention Needed (CAN) interrupt before the adapter cluster receives another character (thus destroy- 
ing the previous character): 



BUFOVFL 



BUFOVFL:NULL 



BUFOVFL: (label) 



BUFOVFL: ABORT 



sets TRUE the (bit variable) BUFOVFL, and branches control to the next 
sequential statement* 

causes no action. Execution proceeds as if the error condition did not 
occur. 

sets TRUE the (bit variable) BUFOVFL, and branches control to 
(label)- 

sets TRUE the (hit variable) BUFOVFL, and executes an implicit 
TERMINATE ERROR. 



CONTINUE 



This option is allowed only in (receive statements of (control definitions and (request definition) s 
that are written to communicate with full duplex terminal types. CONTINUE syntax causes action as 
described below if the co-line executes a (continue statement) bzfotv specified by the 

(receive statement) is received. 



CONTINUE 
CONTINUE:NULL 

CONTINUE: (label) 
CONTINUE : ABORT 
CONTROL 



branches control to the next sequential statement. 

causes no action. Execution proceeds as if the (continue statement) had 
not been executed. 

branches control td\(label). 

Not allowed. . \ 



The CONTROL option variations cause the following actions if the control character of the station (as 
defined in the (station control character statement)) is received: 



CONTROL 



CONTROL:NULL 



CONTROL: (label) 



CONTROL: ABORT 



sets TRUE the (bit variaMe) CONTROLFLAG, and branches control 
to the next sequential statement. 

sets TRUE the (bit variable* CONTROLFLAG, and execution continues 
as if the character was not tie station's control character. 

sets TRUE the (bit variable) IcONTRO LFL AG, and branches control to 
(label). 

Not allowed. 
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CRCERR 



The following CRCERR option variations cause the following actions if the first character received does 
not equal CRC|0| , or the second character received does not equal CRC| 1 | . (This item is*appropriate 
only for the RECEIVE CRC form of the (receive statement) ; refer to the CRC option.) 

CRCERR sets TRUE the (bit variable) CRCERR, and branches control to the next 

sequential statement. 



CRCERRrNULL 
CRCERR : (label) 
CRCERR : ABORT 



causes no action. Execution proceeds as if the error did not occur, 
sets TRUE the (bit variable) CRCERR, and branches control to (label). 
Not allowed. 



END 



The END option variations cause the following actions if the "end" character of the station (as defined 
by the (terminal end character statement) in the (terminal definition) associated with the station) 
is received: 



END 

ENDNULL 

END:</tf/W> 
END: ABORT 



causes control to branch to the next sequential statement. 

causes no action. Execution proceeds as if the character was not the 
44 end" character. 

branches control to (label). 

Not allowed. 



FORMATERR 



The following variations of the FORMATERR option cause the following actions if the characters received 
are not equal to those in the (string) (this item is appropriate only for the RECEIVE (string) construct of 
the (receive statement)): 

sets TRUE the (bit variable) FORMATERR, and 
branches control to the next sequential statement. 



FORMATERR 
FORMATERRrNULL 
FORMATERR: (label) 



causes no action. Execution proceeds as if the 
error did not occur. 

sets TRUE the (bit variable) FORMATERR, and 
branches control to (label). 



FORMATERR:ABORT 



not allowed. 
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LOSSOFC A R R I ER 

The LOSSOFCARRIER option variations cause the following actions if a loss of carrier is detected while 
receiving. 



sets TRUE the (bit variable) LOSSOFCARRIER, and branches 
control to the next sequential statement. 

causes no action. Execution proceeds as if the error did not 
occur. 

sets TRUE the {bit variable) LOSSOFCARRIER, and branches 
control to (label). 

sets TRUE the (bit variableY LOSSOFCARRIER, and executes 
an implicit TERMINATE ERROR 

There is one exception to the actions described above. If a loss of carrier is detected while receiving, 
and if the terminal is modem-connect, and if the terminal's (station definition) references a (modem 
definition) that contains the statement LOSSOFCARRIER=DlSCONNECT, then an implicit dis- 
connect is done, regardless of the action specified. 



LOSSOFCARRIER 
LOSSOFCARRIER :NULL 
LOSSOFCARRIER:</a6e/> 
LOSSOFCARRIER: ABORT 



PARITY 

The PARITY option variations cause the following actions if a parity bit error is detected by the adapter 
cluster: 



PARITY 

PARITY:NULL 
PARITY: (label) 

PARITY:ABORT 



sets TRUE the (bit variable) PARITY, and branches control to the 
next sequential statement. 

causes no action. Execution proceeds as if the error did not occur. 

sets TRUE the (bit variable) PARITY, and branches control to 

(label). 

sets TRUE the (bit variable) PARITY, and executes a 
TERMINATE ERROR. 



STOPBIT 



The STOPBIT option variations cause the described actions if a stop bit error is detected by the adapter 
cluster: 



STOPBIT 

STOPBIT:NULL 
STOPBIT: (label) 

STOPBIT: ABORT 



sets TRUE the (bit variable) , and branches control to the next 
sequential statement. 

causes no action. Execution proceeds as if the error did not occur. 

sets TRUE the (bit variable) STOPBIT, and branches control to 
(label). 

sets TRUE the (bit variable) STOPBIT, and executes a 
TERMINATE ERROR. 
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TIMEOUT 



The TIMEOUT option variations cause the actions described if the time required to receive a character 
exceeds the (timeout time). The (timeout time) is defined in the (terminal timeout statement) , but 
can be overridden by including the ( (timeout time) ) or (NULL) syntax options in the (receive 
statement). 



TIMEOUT 

TIMEOUT:NULL 
TIMEOUT: (label) 

TIMEOUT: ABORT 



sets the (bit variable) TIMEOUT, and branches control to the 
next sequential statement. 

causes no action. Execution proceeds as if the error did not occur. 

sets TRUE the (bit variable) TIMEOUT, and branches control to 
(label). 

sets TRUE the (bit variable) TIMEOUT, and executes a 
TERMINATE ERROR. 



TRANERR 



The TRANERR option variations cause the described actions if the characters received and the 
Receive Transmission Number stored in the Station Table are not equal (this item is allowed only in 
the RECEIVE TRAN construct of the (receive statement)): 

TRANERR sets TRUE the (bit variable) TRANERR, and branches control 

to the next sequential statement. 



TRANERR:NULL 
TRANERR: (label) 



TRANERR: ABORT 



causes no action. Execution proceeds as if the error did not occur. 

sets TRUE the (bit variable) TRANERR, and branches control to 
(label). 

not allowed. 



WRU 



The WRU option causes the following actions if the WRU character of the station is received (the 
(station WRU character statement) defines the WRU character): 



WRU 

WRU:NULL 
WRU:</a/>e/> 
WRU: ABORT 



sets TRUE the WRU (bit variable), and branches control to the 
next sequential statement. 

sets TRUE the WRU (bit variable) , and execution proceeds as if 
the character received was not the WRU character. 

sets TRUE the (bit variable) WRU, and branches control to 
(label). 

not allowed. 



5-36 



Definitions 



CONTROL 

Receive Statement - Continued 



^single character) 

The (single character) syntax causes the following actions if a character received is equal to the (single 
character) : 



(single character) 
(single character) :NULL 

(single character) : (label) 
(single character) : ABORT 



branches control to the next sequential statement. 

causes no action. Execution proceeds as if the character received 
was not equal to the (single character). 

branches control to (label). 

not allowed. 



The allowable combinations of the (receive statement) syntax options are defined in table .5-2. The (NULL) 
and ((timeout time)) options are allowed in any form of the (receive statement) . Allowed combinations 
of the other syntax options are denoted by a "X" in the appropriate columns and rows. 



Supplementary Examples 

Statement 



RECEIVE (3 SEC) [TIMEOUT: 10]. 



RECEIVE ADDRESS [ADDERR:99]. 



RECEIVE CHARACTER [CONTINUE. 10, 

CONTROL:20, 
TIMEOUT:30, 
"*":40J. 



Explanation 

Causes the adapter cluster to attempt to receive a 
character. If the character is not received within 
3 seconds, the (bit variable) TIMEOUT is set 
TRUE and control branches to 1 0. 

If the character(s) received do not equal those 
defined in the (station address statement) , the 
(bit variable) ADDERR is .set TRUE, and control 
branches to 99. 

This statement would only be allowed in a 
(control definition) or (request definition) that is 
written to communicate with full duplex terminal 
types because it contains the CONTINUE option. 

CONTINUE: 10 would cause a branch to 10 if the 
co-line (control definition) executes a (continue 
statemen t) before a character is received. 

CONTROL: 20 would set CONTROLFLAG TRUE 
and branch to 20 if the character received is the 
station's control character. 

TIMEOUT: 30 would set TIMEOUT TRUE and 

branch to 30 if a character is not received within 
the (timeout time) defined in the (terminal 
timeout statement). 

u *":40 would cause a branch to 40 if the character 
received is the asterisk character. 



5-37 



Definitions 
CONTROL 
Receive Statement - Continued 



Statement 



RECEIVE[ERROR[0] ] . 



RECEIVE[0] 



Table 5-2. Allowable Combinations for {receive statement) 





ADDERR 

BCCERR 

BREAK 

BUFOVFL 

CONTINUE 

CONTROL 

CRCERR 

END 

FORMATERR 

LOSSOFCARRIER 

PARITY 

STOPBIT 

TIMEOUT 

TRANERR 

WRU 

(single character) 


ADDRESS 

ADDRESS(RECEIVE) 

ADDRESS(TRANSMIT) 

BCC 

CHARACTER 
CRC 

(string) 
TRAN 


X XXX X X X X 
X XXX X X X X 
X XXX X X X X 
X X X X X X X X 

X X X X X X X X X X X 
XXX X X X X X 
XXX X X X X X 
X X X X X X X X 



Explanation 



An attempt is made to receive one character and 
store it in CHARACTER. If any errors described 
in the associated (error switch statement) occur 
while receiving, then the action defined in that 
(error switch statement) is taken. 

Same as above. 
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SHIFT STATEMENT 
Syntax 



SHIFT - 



-^UP 



•DOWN- 



Semantics 

The (shift statement) is to be used in a (control definition) that communicates with stations using the 
Baudot (5-bit) character code set. (The character code set is defined in the (terminal code statement} of 
the associated (terminal definition) ). 

SHIFT UP indicates that received characters are to be translated to their respective uppercase graphics 
(usually referred to as FIGS). 

SHIFT DOWN indicates that receive characters are to be translated to their respective lowercase graphics 
(usually referred to as LTRS). 

If the station does not use Baudot code, the (shift statement) acts as a no-op. 
Pragmatics 

In the Baudot character code set, most bit patterns have two graphic representations: one is referred to as 
FIGS (the uppercase graphic), and the other as LTRS (the lowercase graphic). 

When transmitting to a terminal that uses Baudot code, the terminal prints LTRS until it receives a specially 
designated character indicating that it should shift to printing FIGS. The terminal continues printing the 
FIGS until it receives a specially designated character indicating that it should resume printing the LTRS. 

When the information is received from a terminal that uses Baudot, the same conventions hold true; that is, 
the terminal communicates whether FIGS or LTRS follow by the transmission of a designated character. 
The terminal initially transmits LTRS. 
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SUM STATEMENT 

Syntax 
SUM 

-*-AI - 
♦ BCC 



CHARACTER- 



RETRY- 



■TALLY- 



»(tally number) - 



-(single character)- 



Examples 
SUMAI. 

SUM CHARACTER. 

SUM "A". 

SUM TALLY [1]. 

Semantics 

The purpose of the (sum statement) is to affect the calculation of the horizontal parity check (whether that 
be a Block Check Character or a Cyclic Redundancy Check). The specific effect of the (sum statement) is . 
dependent upon two factors: the SUMmed item, and whether the station's (terminal definition) for which 
(control definition) is running, defines horizontal parity as CRC( 16). 

Following is a description of the effect that each form of the (sum statement) has on the calculation of the 
horizontal parity check. Any reference to CRC means CRCfOj and CRC[1] collectively. 

SUM 

Semantically equivalent to SUM CHARACTER. 
SUM AI 

If the horizontal parity check is a Block Check Character or is undefined, the contents of AI are exclusively 
OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of AI and CRC, and the result is stored in CRC. 

SUM BCC 

If the horizontal parity check is a Block Check Character or is undefined, then the contents of BCC are 
exclusively OR-ed with itself, and the result is stored in BCC. (The result in BCC would be zero in this 
case.) 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of CRC|0| and CRC, and the result is stored in CRC. 
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SUM CHARACTER 

if the horizontal parity check is a Block Check Character or is undefined, the contents of CHARACTER are 
exclusively OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of CHARACTER and CRC, and the result is stored in CRC. 

SUM RETRY 

If the horizontal parity check is a Block Check Character or is undefined, the contents of RETRY are exclu- 
sively OR-ed with the contents of BCC, and the result stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of RETRY and CRC, and the result is stored in CRC. 

SUM TALLY [(tally number)] 

If the horizontal parity check is a Block Check Character or is undefined, the contents of TALLY [ (tally 
number)] are exclusively OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of TALLY | (tally number) ] and the result is stored in CRC. 

SUM (single character) 

If the horizontal parity check is a Block Check Character or is undefined, the (single character) is exclu- 
sively OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check, the Cyclic 
Redundancy Check algorithm is computed with the (single character) and CRC, and the result is stored in 
CRC. 
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TRANSMIT STATEMENT 
Syntax 
TRANSMIT- 



-•-ADDRESS 



-»>BCC 



C RECEIVE 
TRANSMIT 



X 



7 



CHARACTER - 



•CRC- 



SEQUENCE 
-*-TRAN 

-(string) — 



U^-^BREAK 



: (label)-*- 
NULL-** 



T 



Examples 



TRANSMIT. 

TRANSMIT CHARACTER |BREAK:NULL| 
TRANSMIT SOH STX 4"00"| BREAK: 101 
TRANSMIT TRAN 

TRANSMIT ADDRESS (TRANSMIT) | BREAK 1. 

Semantics 

The (transmit statement") causes the adapter cluster to transmit information to a terminal. The following 
group of syntax options specifies the information to be transmitted. All options except CHARACTER 
use the (byte variable} CHARACTER as a temporary storage area; thus, any information contained in 
CHARACTER before execution of the (transmit statement) shall be destroyed by the (transmit statement) . 
If none of the first group of options is chosen, it is semantically equivalent to specifying CHARACTER 
(i.e., 'TRANSMIT;' is equivalent to TRANSMIT CHARACTER.' ). 

ADDRESS 

The proper number of characters (as specified by the station's associated (terminal definition} in the 
(terminal address size statement) ) are taken from the address field in the Station Table and transmitted. 

ADDRESS (RECEIVE) 

This option is equivalent to ADDRESS, except that ADDRESS (RECEIVE) must be used when an 
address pair is defined in the (station address statement) and the programmer wants to transmit the 
receive address. 
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ADDRESS (TRANSMIT) 

This option is equivalent to ADDRESS, except that ADDRESS (TRANSMIT) must be used when an 
address pair is defined in the (station address statement) and the programmer wants the transmit address 
transmitted. 

BCC 

The BCC option causes the contents of the (byte variable) BCC to be transmitted. 
CHARACTER 

The CHARACTER causes the contents of the (byte variable) CHARACTER to be transmitted. 
CRC 

This option causes two bytes to be transmitted; the contents of CRC [0] are transmitted first, followed 
by CRC [ 1 J . If the station's associated (terminal definition) does not define horizontal parity as 
CRC ([16] ), the use of this (option) causes a syntax error to be generated at compile time. 

SEQUENCE 

The SEQUENCE option causes the character representation of the value stored in the Sequence field 

of the Station Table to be transmitted if the station is in sequence mode (i.e., this (bit variable) SEQUENCE 

is TRUE); otherwise, the (transmit statement) is a no-op. 

TRAN 

The proper number of transmission number characters (as defined by the station's associated (terminal 
definition) in the {terminal transmission number length statement) ) are extracted from the Transmit 
Transmission Number field in the Station Table and then transmitted. 

(suvt<;) 

Each character of the (string) is transmitted. 

The BREAK syntax allows the programmer to specify action if a "break" is received from the terminal 
while the adapter cluster is still transmitting. If this option is omitted and a break occurs, an implicit 
TERMINATE ERROR is executed. The following describes the actions of the three syntactical forms: 

BREAK sets TRUE the (bit variable) BREAK [TRANSMIT] , and causes 

a branch of control to the next statement. 

BREAK: (label) sets TRUE the (bit variable) BREAK (TRANSMIT] , and causes 

a branch of control to (label) . 



BREAK-NULL 



causes no action. Execution proceeds as if the break did not occur. 
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WAIT STATEMENT 



Syntax 



WAIT 



(wait time)* 



- (label)' 



Examplcs 



WAIT. 

WAIT (3 SEC). 
WAIT(5MILLI:6). 

Semantics 

The (wait statement) is only allowed in (control definitions that are written to communicate with 
full duplex terminal types. Execution of this statement causes the (control definition) to be suspended 
until the co-line executes a (continue statement). The optional syntax effects the statement as described 
below: 



(wait time) 



( wait time): (label) 



defines the maximum amount of (time) that the (control 
definition") should be suspending waiting for the (continue 
statement). If (wait time) is exceeded and the co-line has 
not executed a (continue statement), execution resumes at 
the next sequential statement. 

same as above except execution resumes at (label) if a 
(continue statement) is not executed within (vva/7 time). 



Pragmatics 

Refer to the (fork statement) pragmatics. 
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DCP DEFINITION 
Syntax 



DCP- 



■ (DCP number) 



(DCP exchange statement)- — - 
(DCP memory size statement) -+> 
(DCP terminal statement) 



Example 

DCP 1: 

MEMORY = 8196. 
EXCHANGE = 2. 

TERMINAL = SOMETERMINALNAME. 

Semantics 

The {DCP definition) is the means by which the programmer defines attributes of each Data Communi- 
cations Processor (DCP) in the Data Communications System. 

The (DCP number) identifies the DCP and must correspond to an address (ranging from through 7) 
wired into each DCP by the field engineer. The attributes of the DCP are defined subsequently by means 
of {DCP statements. A maximum of eight DCP definitions may appear in the NDL source program. 

Each {DCP statement) is described subsequently. 
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DCP EXCHANGE STATEMENT 
Syntax 

EXCHANGE . » ■ = — -*»(DCP number)- - — — 

Example 

EXCHANGE = 4. 
Semantics 

The (DCP exchange statement) specifies that the DCP shares hardware-exchanged adapter clusters with 
another DCP. (DCP number) defines the other DCP. 

This statement is required in any (DCP definition) referenced by a (DCP exchange statement) in another 
(DCP definition), or in any (DCP definition) that does not have lines defined for it in the (line definition) 
section of the source program. 

Pragmatics 

The maximum number of DCPs that can share a set of adapter clusters is 2. The definitions of both DCPs 
that share adapter clusters must contain a (DCP exchange statement) naming the (DCP number) of the 
DCP with which it shares the adapter clusters. For example, if DCP 1 and DCP 2 share adapter clusters, 
then the definition of DCP 1 must contain the statement 

EXCHANGE = 2. 

and the definition of DCP 2 must contain the statement 
EXCHANGE = 1. 

If a DCP shares adapter clusters with another DCP, then any adapter cluster connected to either of the 
DCPs must be shared by both. A DCP is not allowed to share only a portion of its adapter clusters. 

LINE SECTION REQUIREMENTS 

If two DCPs share adapter clusters, it is required that the (line definition) s for each DCP be given addresses 
(by means of a (line address statement) ) such that both DCPs do not have lines defined on the same 
cluster. 

The following program segment would cause the compiler to generate a syntax error because both DCPs 
have lines defined on adapter cluster 0. 
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DCP Exchange Statement - Continued 

LINE L100: 

ADDRESS * 1:0:0. % ADDRESS * <DCP> :< AD AFTER CLUSTER) :<LINE>. 



LINEL201: 

ADDRESS = 2:0:1. 



DCP1: 

MEMORY = 8192. 
EXCHANGE = 2. 

DCP 2: 

MEMORY =8192. 
EXCHANGE =1. 

MCS RECONFIGURATION 

The EXCHANGE CLUSTERS (TYPE =129) DCWRITE function allows a Message Control System to 
transfer control of any or all adapter clusters, that are exchanged by two DCPs, from the DCP that cur- 
rently controls the designated adapter clusters to the DCP with which it is exchanged. This aspect of the 
reconfiguration feature may be invoked in order to provide an installation with the ability to effect 
"load-leveling" between two DCPs that share hardware-exchanged adapter clusters or to transfer all of 
the work load of a DCP to its partner if the DCP malfunctions. For more information regarding recon- 
figuration, refer to the B 6700/B 7700 DCALGOL Reference Manual , form no. 5000052. 

Supplementary Example 

The following is a program segment describing the data communications system illustrated in figure 5-1 . 
This example illustrates how the (tine definition) and (DCP definition) sections can be written to 
describe a data communications system in which two DCPs share hardware-exchanged adapter clusters. 
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- Continued 



% 

%STATION DEFINITION SECTION. 

% 

STATION DEFAULT ALLSTATIONS: 



STATION STAI: 

DEFAULT = ALLSTATIONS. 
TERMINAL = TTY, 

STATION STA2: 

DEFAULT = ALLSTATIONS. 
TERMINAL = TTY. 

STATION STA3: 

DEFAULT = ALLSTATIONS. 
TERMINAL = TTY. 

STATION ST A4: 

DEFAULT = ALLSTATIONS. 
TERMINAL = TTY. 

STATION STA5: 

DEFAULT = ALLSTATIONS. 
TERMINAL = TTY. 

STATION STA6: 

DEFAULT = ALLSTATIONS. 
TERMINAL = TTY. 

% 

%LINE DEFINITION SECTION. 

% 

%%%%%%%%%%%%%% LINES FOR DCP %%%%%%%%%%%%%% 



LINE L000: 



ADDRESS 
ADAPTER 
STATION 



0:0:0. 

l(DIRECT). 

STAI. 



LINE L001 ; 



ADDRESS 
ADAPTER 
STATION 



0:0:1. 
l(DIRECT). 
ST A 2. 



5-48 



Definitions 
DCP 

DCP Exchange Statement - Continued 



LINE L020: 



ADDRESS = 0:2:0. 
ADAPTER = l(DIRECT). 
STATION = ST AS. 



LINEL021: 



ADDRESS =0:2:1. 
ADAPTER = l(DIRECT). 
STATION = STA6. 



% 

%DCP DEFINITION SECTION 



LINE L1 10: 



ADDRESS * 1:1:0. 
ADAPTER = l(DIRECT). 
STATION = STA3. 



LINE Llll: 



ADDRESS = 1:1:1. 
ADAPTER = l(DIRECT). 
STATION = STA4. 



DCP 0: 



DCP1: 



MEMORY =8192. 
EXCHANGE =1. 



MEMORY =8192. 
EXCHANGE = 0. 
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ADAPTER TELETYPE 
DCfs CLUSTERS LINES TERMINAL STATIONS 



DCP 



DCP 1 




Figure 5-1. Adapter Clusters Exchange 
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DCP MEMORY SIZE STATEMENT 
Syntax 

MEMORY— ^(integer) 



Examples 

MEMORY = 4096. 
MEMORY * 0. 

Semantics 

The (DCP memory size statement) defines the number of words of local memory in the DCP being 
defined. 

A zero value for (integer) indicates that the DCP has no local memory and that all code generated for 
the DCP shall reside in main system memory. A non-zero value for (integer) that is less than the amount 
of local memory required, as determined by the compiler, results in a compile-time error. 
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DCP TERMINAL STATEMENT 



Syntax 



TERMINAL 




(terminal identifier} 




L^-C-** MSGSPACE = (integer)— +») 



Examples 



TERMINAL 
TERMINAL 



TELETYPE. 

M33, TD800 (MSGSPACE = 5), TELETYPE (MSGSPACE * 2). 



Semantics 



The purpose of the (DCP terminal statement) is twofold. Each aspect of this statement is discussed in 
the subsequent two paragraphs. 

The primary purpose of the (DCP terminal statement) is to provide the means of specifying which 
terminal types in the data communications network that the DCP must be able to control. Only those 
terminal types specified in this statement will have the object code required to control them included 
in the object code generated for the DCP. If this statement is omitted from a DCP definition, the com- 
piler includes the object code required to control all terminal types in the data communications network. 

The second purpose of the (DCP terminal statement) is to provide a means of specifying the initial 
number of message spaces allotted for each terminal type controlled by the DCP. 

The (terminal identifier) must name a terminal type defined by a (terminal definition) , and specifies 
a terminal type for which the DCP must have access to the controlling code. 

The (MSGSPACE = (integer) ) option specifies the number of message spaces initially allotted for the 
terminal type. If this option is omitted, two message spaces are allotted by default. 



Note that if any terminal type is not named in the (DCP terminal statement) , the data communications 
network may not be reconfigured (by means of a reconfiguration DCWRITE in an MCS) such that it adds 
that terminal type to those terminal types controlled by the DCP. Refer to the supplementary example 
that follows. 

Supplementary Example 

The program segment below illustrates the pragmatics. A station whose terminal type is SCREENDEVICE 
cannot be added on the spare line L003 of DCP 1 , because DCP 1 does not have the code available to 
control SCREENDEVICE. 



Pragmatics 
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Continued 



%CONTROL & REQUEST DEFINITION SECTION. 

% 



REQUEST READTTY: 



REQUEST WRITETTY: 



The object code generated from these state- | 
merits is required to control TTY terminal ? 
types. ; 



REQUEST READSCREENDEVICE: 



REQUEST WRITESCREENDEVICE: 



The object code generated from these state- 
ments is required to control SCREENDEVICE 
terminal types. 



% 

%TERMINAL DEFINITION SECTION. 

% 

TERMINAL DEFAULT DEFAULTLIST: 



BLOCK 

SCREEN 

TURNAROUND 

ICTDELAY 

TRANSMISSION 

DUPLEX 

TIMEOUT 

ADDRESS 

PAGE 

CODE 

INHIBITSYNC 

BUFFER 

MAXINPUT 

WIDTH 

PARITY 

ADAPTER 

WRU 

END 

BACKSPACE 
CONTROL 



FALSE. 

FALSE. 

0. 

0. 

0. 

FALSE. 
3 SEC. 
0. 
0. 

ASC67. 

FALSE. 

NULL. 

80. 

72. 

NULL. 
4. 

ENQ. 

ETX(DYNAMIC). 

BS(DYNAMIC). 

CONTENTION. 
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TERMINAL TTY: 



DEFAULT 
REQUEST 



DEFAULTLIST. 

WRITETTY:TRANSMIT,READTTY:RECEIVE.*- 



TERMINAL SCREENDEVICE: 



DEFAULT 

SCREEN 

REQUEST 



DEFAULTLIST. 
TRUE. 

WRITESCREEN DEVICE :TRANSM IT,READSCREENDEVICE : < 
RECEIVE. 

! These statements specify the (request 
definitions) required to control the 
defined terminal type. The object code 
generated by the procedures named here 
must be accessible by a DCP that has the 
terminal type attached to any of its lines. 



% 

%STATION DEFINITION SECTION. 

% 

STATION DEFAULT ALLSTATIONS: 



ENABLEINPUT 
LOGIC A LACK 
MCS 

CONTROL 

RETRY 

MYUSE 

STATION STA1 : 

DEFAULT 
TERMINAL 

STATION STA2: 

DEFAULT 
TERMINAL 

STATION ST A3: 

DEFAULT 
TERMINAL 

STATION STA4: 

DEFAULT 
TERMINAL 

STATION STA5: 

DEFAULT 
TERMINAL 

STATION STA6: 

DEFAULT 
TERMINAL 



TRUE. 
FALSE. 

SYSTEM/CANDE. 

QM. 

15. 

OUTPUT,INPUT. 



ALLSTATIONS. 
TTY. 



ALLSTATIONS. 
TTY. 

ALLSTATIONS. 
TTY. 

ALLSTATIONS. 
SCREENDEVICE. 

ALLSTATIONS. 
SCREENDEVICE. 

ALLSTATIONS. 
SCREENDEVICE. 



A (line definition) naming any of these 
stations must be a (line definition) for 
DCP 0. DCP 1 does not have access to 
code required to control terminals 
associated with these stations. 



A (line definition) naming any of these 
stations must be a (line definition) for 
DCP 1. DCP does not have access to 
code required to control terminals 
associated with these stations. 
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% 

%L1NE DEFINITION SECTION. 

%%%%%%%%%%%%%% LINES FOR DCP 



%%%%%%%%%%%%%%%%%%%%%%% 



LINE L000: 

ADDRESS 
ADAPTER 
STATION 

LINE L001 : 

ADDRESS 
ADAPTER 
STATION 

LINE L002: 

ADDRESS 
ADAPTER 
STATION 



0:0:0. 
1 (DIRECT). 
STA1. 



0:0:1. 

1 (DIRECT). 

STA2. 



0:0:2. 

1 (DIRECT). 

ST A3. 



\ 



The (line station statement') of any (line 
definition) for DCP must name a station 
that has a TTY terminal type associated with 1 
it. DCP does not have access to code 
required to control SCREENDEVICE ter- 
minal types. 



LINE L003 : % THIS IS A SPARE LINE 



ADDRESS 
MAXSTATIONS 

%%%%%%%%%%%%%%%% 

LINE L100: 

ADDRESS 
ADAPTER 
STATION 

LINEL101: 

ADDRESS 
ADAPTER 
STATION 

LINE LI 02: 

ADDRESS 
ADAPTER 
STATION 

% 

%DCP DEFINITION SECTION. 

% 



= 0:0:3. 
= 1. 

LINES FOR DCP 1 %%%%%%%%%%%%%%%%%%%%% 



1:0:0. 

I(DIRECT). 
STA4. 



1:0:1. 

1 (DIRECT). 
STA5. 



1:0:2. 

1 (DIRECT). 
STA6. 



The (line station statement') of any (line 
definition) for DCP 1 must name a station 
that has a SCR EEN DEVICE terminal type 
associated with it. DCP 1 does not have 
access to code required to control TTY 
terminal types. 



DCP0: 



MEMORY 
TERMINAL 



DCP 1: 



MEMORY 
TERMINAL 



8192. 
TTY. 



8192. 

SCREENDEVICE. 



!The effect of this statement is that this DCP ) 
has access to control code for TTY terminal / 
types only. ) 

The effect of this statement is that this DCP \ 
has access to control code for SCREEN- > 
DEVICE terminal types only. ) 
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FILE DEFINITION 

Syntax 

FILE *~(file identifier) s*»: e** (file family statement)- 

Example 

FILE NETWORK: FAMILY = ST ATION ID 1, STATION ID2, FILEID1. 
Semantics 

The (file definition) provides the means to define a data communications file and specify the stations 
associated with that file. The {file identifier) is the external name (TITLE) of the file, and has the syntacti- 
cal form of a (system identifier) . 

A single-station file is a file that has one station associated with it. A single-station file can, but need not, 
be formally defined in a (file definition) . The reason that a single-station file does not need to be defined 
is that each station is itself a file. The external name (TITLE) of such a file would be the (station identi- 
fier) of the station. 

A multi-station file is, as the name implies, a file that has more than one station associated with it. Multi- 
station files must be defined in (file definitions. 

Pragmatics 

A general discussion of data communication files and their peculiarities can be found in chapter 2 of the 
BilZQO Input/Ou tput Subsystem Information Manual form no. 5000185, under the heading "DATA 
COMM FILES." The information contained in that discussion is a prerequisite to understanding the 
significance of (file definition) s. Chapter 3 of the same manual contains a table that lists all file attributes 
and provides an explanation of each attribute. Attributes relative to data communication files are found 
by examining the "KIND" column of the table for the key word "Datacom." The information found 
in the explanation of each data communications-relative attribute is also a prerequisite. 

A detailed discussion of data communications object job I/O can be found in appendix B of the B 6700 / 
B 7700 D CALC OL Reference Manual form no. 5000052, under the semantics of STATION ASSIGNMENT 
TO FILE (TYPE = 64). The information found there is not considered a prerequisite; however, it does 
contribute toward a deeper understanding of data communications files and data communications object 
job I/O. 



I 
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FILE FAMILY STATEMENT 
Syntax 



FAMILY 



-n*~(file identifier)- 



y (station identifier) 



Example 

FAMILY = STATIONID1, ST ATIONID2, FILEID1. 
Semantics 

The (file family statement) defines the stations associated with a data communications file. If a (file 
identifier) is named, all of the stations associated with the file named will also be associated with the 
file being defined. Any duplication of an (identifier) in a (file family statement) is ignored. 

Supplementary Example 

The following example is the {file definition) section of a hypothetical NDL program. Assume that the 
stations STATION 1 , STATION2, ST ATI ON 3, STATION4, STATION5, STATION6, STATION 7, and 
STATION8 have been defined in the (station definition) section. 



FILE TTYS: 

FAMILY = STATION 1 , STATION2, STATIONS. 



FILE CRTS: 

FAMILY = STATION4, STATIONS, STATION6. 



FILE EXECUTIVES: 

FAMILY = STATION 1 , CRTS, STATION6, STATION 7. 



FILE THE/ENTIRE/NETWORK: 

FAMILY = STATION"?, STATION8, TTYS, CRTS. 



/ TTYS is the (identifier) of this* 
) file. The FAMILYSIZE is 3. 
< STATION 1, STATION 2, and 
/ STATION3 are the stations 
V associated with this file. 

CRTS also has a FAMILYSIZE 
of 3. The stations associated 
with the file are STATION4, 
STATION5, and STATION6. 

(EXECUTIVES has a FAMILY- 
SIZE of 5. The stations 
associated with the file are 
STATION!, STATION4, 
STATIONS, STATION6, and 
STATION7. 

THE/ENTIRE/NETWORK has 
a FAMILYSIZE of 8. The 
stations associated with THE/ 
ENTIRE/NETWORK are 
STATION l,STATION2, 
STATION3, STATION4, 
STATION5, STATION6, 
STATION 7, and STATION8. 
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LINE DEFINITION 
Syntax 



LINE 



(line iih'iitifivrS r*- : 

r 

ine identifier) — I 



DEFAULT^ line identifier) 



-m-(line adapter class statement ) ~ 

(line address statement ) * 

-+*(jine answer statement ) * 

(line default statement ) — 



-*> (line endofnumber statement ) d» 

-a»(line maxstations statement) b» 

-b*. (line modem statement) ». 

• (line phone statement) *» 

• (line station statement) »• 

•(line type statement)- »■ 



Examples 



LINE TTYDIALIN: 
TYPE 
ADAPTER 
MODEM 
ANSWER 
PHONE 
ADDRESS 
STATION 
MAXSTATIONS 



= DIALIN. 
= 1 (MODEM). 
= TTYMODEM. 
= TRUE. 
= 2139686521. 
= 0:0:0. 

= TTYSTATION. 
= 1. 



LINE DEFAULT LINEDEFAULTLIST1 . 



ADAPTER 

ANSWER 

ENDOFNUMBER 

MAXSTATIONS 

TYPE 

MODEM 



= 1 (MODEM). 
= TRUE. 
= FALSE. 
= 1. 

= DIALIN. 

= TTYMODEM. 



Semantics 

{line identifier) and (default line identifier) both have the same syntactical form as (identifier). 
Each form of the (line definition) syntax is described subsequently. 
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LINE (line identifier) : . . . 

This form of the (line definition) defines the attributes of a logical line in the data communications 
network. Line attributes are defined in one of the following ways: 

a. Hach attribute is defined explicitly by means of a (line statement) in the {line definition) . 

b. Each attribute is defined implicitly by an explicit reference to a set of default attribute values. 

c. Some of the line attributes are defined implicitly as in b, and the remainder are defined 
explictly as in a. 

Some (line statements must be defined for each (line definition); others do not. Some of the statements 
may or may not require definition, depending upon the appearance of other statements. The semantics 
portion of each (line statement) states, among other things, whether the attribute must be defined and 
its effect upon the requirements of other attribute definitions. 

To define the attributes of a line as described in item a above, this syntax form must be used. 

To define the attributes of a line as described in items b and c above, this syntax form, the following 
syntax form, and the (line default statement) must be used in conjunction (this is described under the 
following syntax form). 

LINE DEFAULT (default line identifier) : . . . 

This syntax Form is referred to as a Default (line definition) . Its purpose is to decrease the number of 
source statements required to define all of the logical lines in the data communications system. This is 
accomplished in the following manner. Attributes common to several logical lines are defined by means 
of a Default (line definition^. Associated with each Default (line definition) is a (default line identifier). 
Subsequent to the Default (line definition) , any (line definition) that has those attributes in common can 
reference the (default line identifier) , instead of repeating the list. (A (default line identifier) is 
referenced by means of a (line default statement).) The NDL compiler uses the last definition of a line 
attribute, and therefore the programmer can reference a Default (line definition) and change any 
attributes by redefining them in the (line definition). 

In appearance, the Default (line definition) is similiar to the (line definition). The differences are that 
the reserved word DEFAULT follows the reserved word LINE, and that there are no statements that are 
required to be defined in a Default (line definition). 



Definitions 
LINE 

Line Adapter Class Statement 

LINE ADAPTER CLASS STATEMENT 
Syntax 



ADAPTER = * {(integer), value of I thru 8^ 



(MODEM) 



—*»( DIRECT) it- 
Examples 

ADAPTER = 5. 
ADAPTER = 4 (MODEM). 
Semantics 

The (line adapter class statement) identifies the Adapter Class of the line adapter for the logical line and, 
optionally, names the connection type (i.e., modem connect or direct connect). 

The Adapter Class must be compatible with the (communication type number) specified in the (station 
adapter statement) of any station assigned to the line. (Note that all stations assigned to a line must 
have the same (communication type number) defined.) Table 5-3 lists the compatible Adapter Classes 
for each (communication type number). For example, a line having stations assigned to it that define 
a (communication type number) of 4 can name as an Adapter Class either 1 , 2, 3, 4, or 5 (refer to ^ 
table 5-3). On the other hand, a line having stations assigned to it that defines 1 5 as the (communication 
type number) can name only 5 as an Adapter Class. 

If the connection type is named in the statement, it is considered by the compiler as documentation 
only. The compiler determines whether the line adapter or a modem-connect line adapter, by the presence 
or absence of a (line modem statement) for the (line definition) . A syntax error is generated, however, 
if DIRECT is named and a (line modem statement) is present. 

Pragmatics 

LINE ADAPTERS AND ADAPTER CLASSES 

There are 1 3 available line adapters. Three of the 13 are special-purpose line adapters; they are used 
for Touch-Tone® telephone input, Audio-Response lines, and Automatic Calling Units (ACU). The 
remaining 1 are general-purpose line adapters. 

The 1 3 available line adapters are divided into eight "Adapter Classes." The Touch-Tone® , Audio- 
Response, and ACU line adapters comprise Adapter Classes 6, 7, and 8, respectively. The 10 general- 
purpose line adapters comprise Adapter Classes 1 through 5. Adapter Classes 1 through 5 differ primarily 
in the maximum transmission speed at which the line adapters may be operated. Adapter Classes 1 
through 5 each consist of two line adapters, one being a "direct connect," and the other being a "modem 
connect." The direct connect has a terminal attached to it by means of a two-wire or four-wire direct 
connection. The modem connect has a terminal attached to it through modems using an RS232f 
defined interface. Refer to table 5-3 for the Adapter Class and the use of each line adapter. 



t A technical specification published by the Electronic Industries Association establishing the interface W 
requirements between modems and terminals or computers. 
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Table 5-3. Available Line Adapters 



MARKETING 
NUMBER* 


CONNECTION 


USE 


CLASS 


B 6650-1 


Direct 


Two-wire direct connect, asynchronous 
bit-serial transmission up to a maxi- 
mum line speed of 600 BPS, simplex or 
half-duplex. 


1 


B 6650-1 


Modem 


Modem-connected with 100-Series type 
modem using RS232-defined interface, 
asynchronous bit-serial transmission 
up to a maximum line speed of 600 
BPS, simplex or half-duplex. (Two 
required for full duplex.) 


1 


B 6650-2 


Direct 


Same as B 6650-1 D, except maximum 
line speed is 1800 BPS. 


2 


B 6650-2 


Modem 


Same as B 6650-1 M, except with 202- 
Series type modem and up to a maxi- 
mum line speed of 1800 BPS. 


2 


B 6650-3 


Direct 


Same as B 6650-1 D, except maximum 
line speed is 2400 BPS. 


3 


B 6650-3 


Modem 


Modem-connected with 202-Series (asyn- 
chronous) or 201 -Series (synchronous) 
modem using RS232-defined interface, 
bit-serial transmission up to a maxi- 
mum line speed of 2400 BPS, simplex 
or nan -uupiex. ^iwo requireu ior 
full duplex.) 


3 


B 6650-4 


Direct 


Same as B 6650-1 D, except maximum 
line speed is 4800 BPS. 


4 


B 6650-4 


Modem 


Same as B 6650-3M, except maximum 
line speed is 4800 BPS. 


4 


B 6650-5 


Direct 


Same as B 6650-1 D, except maximum 
line speed is 9600 BPS. 


5 


B 6650-5 
B 6650-6 


Modem 


Same as B 6650-3M, except maximum 
line speed is 9600 BPS. 

For Touch-Tone® telephone input. 


5 
6 


B 6650-7 




For Audio-Response line. 


7 


B 6650-8 




For Automatic Calling Unit (ACU). 


8 


The above marketing numbers refer to B 6700 line adapters. B 7700 line adapters have similar 
numbers, the difference being a leading 7 instead of a 6; e.g., B 6650-1 for B 6700, and B 7650-1 for 
B 7700. In this table only, a distinction is made between modem-connected line adapters and direct- 
connected line adapters by affixing either a D (for direct-connected) or an M (for modem-connected) 
to the field marketing numbers (under the "Use" column) which require that distinction. 
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LINE ADDRESS STATEMENT 
Syntax 

ADDRESS -*»=-+»(DCP number)-®* : -+* (adapter cluster number)-®** : -&~(line adapter number}' 



Example 

ADDRESS ~ 2:0:15. 

The above example would appear in the '{line definition) of the line at the 1 5th line adapter position in 
adapter cluster number of DCP number 2. 

Semantics 

The (line address statement) identifies the DCP number, the adapter cluster number, and the line 
adapter number of the defined logical line. If two DCPs share hardware-exchanged adapter clusters 
(as defined by the (DCP exchange statement) in a (DCP definition)), then the (DCP number) defined in 
this statement is the DCP initially expected to service the adapter cluster of which the line is a part. This 
statement, which is required, must be defined explicitly in each (line definition). 
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LINE ANSWER STATEMENT 
Syntax 



ANSWER 



-fls^TRUE 



♦ FALSE • 



Semantics 

The (line answer statement) defines whether or not (TRUE or FALSE, respectively) the DCP is to 
automatically answer an incoming call. This statement is required if the (line type statement) in the 
(line definition) defines the line configuration as DIALIN only, or DIALIN and DIALOUT. 

If ANSWER = FALSE, an incoming call causes the following actions to be taken by the DCP. A SWITCHED 
STATUS RESULT (CLASS = 7) message is sent to the MCS of the station that is the first entry in the 
Line Table for that line. (Unless an MCS has reconfigured the line so that it changes the first entry, the first 
entry in the Line Table will be the entry for the first station listed in the (line station statement) of 
the (line definition).) The message has a bit set in it that indicates the line is in a "ringing" status. 
Presumably , upon notification of a line in a ringing status, the MCS programmer instructs the DCP to 
answer the phone, or it takes appropriate action to clear the line. 

If ANSWER = TRUE, an incoming call causes the DCP to take the following actions. A SWITCHED STATUS 
RESULT (CLASS = 7) message is sent to the controlling MCS of the station that is the first entry in the 
Line Table for that line. In this case the message has a bit set indicating that there has been an incoming 
call, and that the DCP is in the process of answering the call. 

An MCS may change the value of ANSWER after DCP initialization, by means of a SET/RESET 
AUTO-ANSWER (TYPE = 1 02) DCWR1TE. 
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LINE DEFAULT STATEMENT 
Syntax 

DEFAULT ► = -^(default line identifier)- — ' • 

Example 

DEFAULT = DFLTLIST1 . 
Semantics 

The {line default statement) allows the programmer to specify the (default line identifier) of a set of 
default line attributes to be used for a (line definition) whose description is incomplete. It is advantageous 
to group attributes that several lines have in common under a Default (line definition) and list the remain- 
ing attributes under each individual (line definition) . The compiler will then refer to the Default 
(line definition) to complete the (line definition). The (line default statement) is not required to appear 
in a (line definition) ; however, a (line definition) must define all required attributes if a (line default 
statement) does not appear. 

The (line default statement) can appear in a (line definition) or a Default (line definition) . Thus, 
(line default statement)* can be "nested" to combine the attributes of one or more Default (line 
definitions) s. 
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LINE ENDOFNUMBER STATEMENT 
Syntax 



ENDOFNUMBER = 



Semantics 



*TRUE- 



FALSE 



The {line endofnumber statement) applies only to (line definitions that specify the Automatic Calling 
Unit (ACU) Adapter Class in its (line adapter class statement) (e.g., ADAPTER = 8). This statement is 
required for those (line definitions, and specifies whether or not (TRUE or FALSE, respectively) the 
ACU has an "end of number" option. 
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LINE MAXSTATIONS STATEMENT 
Syntax 

MAXSTATIONS ► = ^(integer) 



Example 

MAXSTATIONS = 25. 
Semantics 

The (line maxstations statement) specifies the number of stations that may be assigned to the defined line. 
If this statement does not appear for a line having assigned stations (the (line station statement) lists all 
stations initially assigned to a line), it is assumed that MAXSTATIONS is the number of stations explicitly 
specified as assigned to the line in the {line station statement) The (integer) specified must not equal 0, 
exceed 255, or be less than the number of stations listed in the (line station statement) (if the (line station 
statement) is defined). 

Pragmatics 

This statement informs the compiler of the maximum number of station descriptors required in the Line 

Table of the DCP's table structure. By defining MAXSTATIONS to be greater than the number of stations 

listed in the (line station statement) , an MCS may reconfigure more stations onto the line at some point "~ 

in time after DCP initialization. For information regarding reconfiguration, refer to the B 6700/B 7700 

DCALG OL Reference Manual , form number 5000052. 
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LINE MODEM STATEMENT 
Syntax 

MODEM ► = m» (modem identifier) 



Example 

MODEM = BELL103A. 

Semantics 

The (line modem statement) specifies the modem type that exists on the system end of the physical line. 
(The (station modem statement) in a (station definition) specifies the modem type connected to the line 
on the terminal end.) 

Pragmatics 

The compiler references other portions of the program with this statement, checking for consistency. If, 
for example, the (modem definition) of the (modem identifier) specified in this statement lists any 
/communication type number) s in its (modem adapter statement) that are not compatible with the 
Adapter Class specified in the (line adapter class statement) of the (line definition), then a syntax error 
is generated. Another situation that causes a syntax error to be generated is if the compiler discovers that 
the modem type specified in this statement is not compatible, in respect to the (communication type 
number), with the modem type specified in the (station definition) of a station assigned to the line. 
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LINE PHONE STATEMENT 
Syntax 

PHONE = — ^(integer) — — 

Example 

PHONE = 12136572385. 
Semantics 

The (line phone statement) , implemented for documentation purposes only, documents the telephone 
number of a DIAL1N type line. This statement is optional in a (line, definition). 
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LINE STATION STATEMENT 
Syntax 



-(station identifier)- 



STATION ^ = 

Examples 

STATION = RJEl. 

STATION = DAKOTA/KID, BIDS. 

Semantics 

The (line station statement) is the means by which the NDL programmer associates one of more stations 
with a line. A station that is associated with a particular line is said to be "assigned" to that line. 

This statement is required in those (line definitioii) s that specify DUPLEX in the (line type statement) . 
In all other variations of (line type statement) , this statement is optional. 

If more than one station is named, each station must have the same (communication type number) 
defined in its respective (station adapter statement) . 
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LINE TYPE STATEMENT 
Syntax 



TYPE 



-T 4 DIALIN 



A LOUT 
DUPLEX - 



-»~(line identifier)- 
{line identifier) ■ 



Examples 

TYPE 
TYPE 
TYPE 
TYPE 

Semantics 



DIALIN. 

DIALOUT: ACULINE. 
DUPLEX:AUXLINE. 

DIALIN. DIALOUT: AUTOCALL, DUPLEX:SUPERVISORY. 



The (line type statement') provides the compiler with specific information concerning special logical line 
configurations. This statement is required for (line definition), a whose line utilize either dial-in, dial-out, 
or full duplex hardware facilities. 

DIALIN 

This form identifies the line as a dial-in line. A line that may be dialed from a remote site is a dial-in line. 
The appropriate (line type statement) for this configuration would be: 

TYPE=DIALIN. 

A logical line defined in this manner must include the (line answer statement) and the (line modem 
statement). The (line definition) for such a line could appear as follows: 



LINE D1ALUPLINE: 

TYPE 
ADDRESS 
MODEM 
STATION 
ANSWER 
ADAPTER 



DIALIN. 

0:0:0. 
TTY103A. 
DIALUPSTATION. 
TRUE.. 
1 (MODEM). 



DIALOUT 



This form identifies the line as a dial-out line. A dial-out line is defined as a line that can become connected 
to a remote site as a result of a Message Control System issuing a DIALOUT (TYPE = 98) DCWRITE to the 
line (thereby causing an Automatic Calling Unit (ACU) to dial the phone number of the remote site). The 
TYPE=DIALOUT: (line identifier) syntax of the statement specifies such a configuration. The (line 
identifier) names the (line definition) that defines the associated ACU. The following example illustrates 
how the (line definition) s could appear for a dial-out configuration. 



LINE DIALOUTLINE: 
TYPE 
ADDRESS 
MODEM 
ADAPTER 



= DIALOUT: ACULINE. 

= 0:0:1. 

= TTY103A. 

= 1 (MODEM) 
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I.INI A< IH INI'. 

I NDOI NUMHl.R - 1A1.SE. 
ADDRESS = 0:0:5. 

ADAPTER =8. 

The (line definition) for the dial-out line must include a (line modem statement) and cannot include a 
(line station statement) . The (line definition) for the ACU must include a (line endofnumber statement) . 
and it must define an address (in t ho (line address statement) ) that is on the same adapter cluster as the 
associated dial-out line. 

DUPLEX 

This form identifies the line as the primary of a line pair, for purposes of simultaneous transmission and 
receptions. The (line identifier) names the auxiliary line's (line definition) . The line referenced as the 
auxiliary cannot contain a (line type statement) nor a (line station statement) . 

The following is an example of how full duplex primary and auxiliary lines could be defined. 

LINE DUPLEXPR1MARY: 

TYPE = DUPLEX: DUPLEXAUXILIARY. 

ADDRESS = 0:0:5. 

MODEM = SUPERMODEM. 

ST\TION = MODEL37. 

ADAPTER =1. 

LINE DUPLEXAUXILIARY: 
ADDRESS = 0:0:6. 
ADAPTER = 1 . 

Pragmatics 

COMBINED CONFIGURATIONS 

A dial-in/dial-out line is characterized by both the ability to be dialed from a remote site, and the ability 
to become connected to a remote site as a result of a Message Control System issuing a DIALOUT 
(TYPE = 98) DCWRITE. This type of configuration requires the DIALIN and DIALOUT: (line identifier) 
options to appear in the (line type statement) . The following example illustrates how a dial-in and dial-out 
(line dejinitioii) could appear: 

LINE IOLINE: 

TYPE = DlALIN,DIALOUT:AUTOCALLUNIT. 

ADDRESS =0:1:0. 

MODEM = TTY103A. 

STATION = REMOTETTY. 

ANSWER = TRUE. 

ADAPTER = 1 (MODEM). 

LINE AUTOCALLUNIT: 

ENDOFNUMBER = FALSE. 
ADDRESS = 0:1:1. 

ADAPTER =8. 
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The full duplex syntax could he combined with the dial-in and dial-out syntax as follows: 



LINE IODUPLEX: 
TYPE 
ADDRESS 
MODEM 
STATION 
ANSWER 
ADAPTER 

LINE AUXLINE: 
ADDRESS 
ADAPTER 



DIALIN,DIALOUT:AUTOCALLUNIT,DUPLEX: AUXLINE. 
0:2:0. 

SUPERMODEM. 

REMOTEDUPLEXDEV1CE. 

TRUE. 

l(MODEM). 

0:2:1. 
l(MODEM). 



LINE AUTOCALLUNIT: 

ENDOFNUMBER = FALSE. 
ADDRESS = 0:2:2. 

ADAPTER = 8. 
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TRUE 



FALSE 



MCS DEFINITION 
Syntax 

MCS »► < MCS identifier > : >■ CONTROL &~ = - 

Examples 

MCS SYSTEM/CANDE:CONTROL = FALSE. 

MCS SYSTEM/DIAGNOSTICMCS:CONTROL = TRUE. 

Semantics 

The purpose of the (MCS definition) is twofold: First, the (MCS definition) adds the (MCS identifier) to 
the list (contained in the Network Information File) of valid Message Control System (MCS) programs; and 
second, the (MCS definition) specifies whether or not (CONTROL = TRUE, or CONTROL = FALSE, 
respectively) the named MCS is allowed to execute a limited set of DC WRITE functions that perform DCP 
diagnostic functions in addition to the standard DCWRITEs. (MCS identifier) has the syntactic form of a 
(system identifier) . 

Pragmatics 

A list of valid MCSs is maintained in the Network Information File in order to restrict unauthorized 
DCALGOL programs from becoming an MCS. (A DCALGOL program becomes an MCS when it success- 
fully executes an INITIALIZE PRIMARY QUEUE (TYPE = 0) DCWRITE.) The MCS declaration is one 
means of adding a name of an MCS to that list. (One other means is the (station MCS statement) in 
a (station definition) .) 

The diagnostic DCWRITE functions allow an MCS to perform on-line tests of components in the Data 
Communications System. Those DCWRITEs that may be utilized in an MCS when CONTROL = TRUE 
have DCWRITE TYPE numbers greater than 1 59. 
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MODEM DEFINITION 
Syntax 



MODEM 



♦ ( modem identifier } 



(modem adapter statement} - 



(modem lossof carrier statement } - 
»» (modem noisedelay statement} — 
(modem transmitdelay statement) - 



Example 

MODEM MABELL103A: 
ADAPTER = 4. 

LOSSOFCARRIER = DISCONNECT. 
NOISEDELAY = 
TRANSMITDELAY = 0. 

Semantics 

The (modem definition} defines the attributes of a modem type in the data communications system. 
The (modem identifier) names the (modem definition} , and has the syntactic form of (identifier}. The 
\modem statements are described subsequently. 
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MODEM ADAPTER STATEMENT 
Syntax 



ADAPTER 



^communication type number} 



^(communication type number)-** i ~^(coninnuu'cati(>n type numbc 



Examples 

ADAPTER = 1,2,3,4. 
ADAPTER = 10. 
ADAPTER = (2,3), (4,5), 6,7. 

Semantics 

The (inodcm adapter statement) defines one or more combinations of character format, synchronous/ 
asynchronous communication, and line speed (in the case of asynchronous communications) witli which the 
modem is compatible. This is done by supplying one or more Communication type number) s (or number 
pairs). 

Table 5-4 lists the allowed (communication type number)s and the characteristics associated with each. 
For example, the statement 

\^ ADAPTER = 4. 

defines an I 1-bit character format, asynchronous communication, at a line speed of 1 10 bits per second. 

if the modem is to be used in a full duplex mode, and the primary and auxiliary lines have different 
characteristics, then one or more (communication type number) pairs must be supplied. For example, the 
statement 

ADAPTER = (11,6). 

defines for the primary line a 10-bit character format, synchronous communication, at a speed of 1 800 bits 
per second. The characteristics associated with the auxiliary line are the same as for the primary line, 
except that the auxiliary line runs at a line speed of 150 bits per second. 

Pragmatics 

COMMUNICATION TYPE NUMBERS 

A (communication type number) is an integer that has associated with it a set of attributes that define 
three line characteristics. Those characteristics are the format of the characters transmitted (start informa- 
tion, data information, parity information, and stop information), whether the line is to be driven 
synchronously or asynchronously, and the speed of the transmissions (in the case of asynchronous 
communications). Table 5-4 lists the allowed Communication type number)s and the line characteristics 
associated with each. 

Most of the electronics that directly control a line are located in the adapter cluster that contains the line 
adapter for that line (rather than being located in the line adapter itself). The adapter cluster is somewhat 
general purpose in its design in that it can run at various line speeds and handle various character formats. 
The DCP can cause the adapter cluster to function in a suitably special-purpose way (with respect to a 
sin S le line) by supplying it a number derived from the (communication type number): 



5-75 



Definitions 
MODEM 

Modem Adapter Statement - Continued 

There are three areas in an NDL program that require the programmer to supply one or more (communica- 
tion type number)s: 

a. In the (tnodem adapter statement) of each (modern definition) , 

b. In the (terminal adapter statement) for each (terminal definition) , and 

c. In the Station adapter statement) for each (station definition) . 

As it encounters each area, the NDL compiler cross-checks to determine if the areas are compatible in their 
description. If inconsistencies in component compatibility arise, syntax errors are generated. Restrictions 
are described in the (terminal adapter statement) and (station adapter statement) semantics. 

EXPLANATION OF TABLE 5-4 

Table 5-4 lists the allowed (communication type number)s in the column labeled "COMM. TYPE NUM." 
To the right of each (communication type number) are the three line ^characteristics ' ^^ed mth it, 
under tte columns laoeled "SPEED (BPS)," "CHARACTER FORMAT, and '^YNCHRONOUS OR 
ASYNCHRONOUS." The rightmost column, labeled "COMPATIBLE ADAPTER CLASSES, is 
referenced and described in the (line definition) section of this chapter. 



«0 
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Table 5-4. Table of (communication type number's 



COMM. 
TYPE 

MI ?A>l 

NUM. 


SPEED 
(BPS) 


CHAR. 
SIZE 
(BITS) 


CHARACTER FORMAT 




COMPATIBLE 
ADAPTER CLASSES 

1 2 3 4 5 6 7 8 


START 
INFO. 


DATA 
INFO. 


PARITY 
INFO. 


STOP 
INFO. 


SYNCHRONOUS 
OR 

ASYNCHRONOUS 


! 


45.5 


7 S 




XU 




1.5 


ASYNC. 


X X X X X 


2 


56.9 


7.5 




< A 




1.5 


ASYNC. 


X X X X X 


3 


75.0 


7.5 




J.U 




1.5 


ASYNC. 


X X X X X 


4 


1 10.0 


11.0 




7 n 
/.u 


J 


2 


ASYNC. 


X X X X X 


5 


134.5 


9.0 




£ o 

O.U 




1 


ASYNC. 


X X X X X 


6 


150.0 


10.0 




7 O 

/ .u 




1 


A OX/XT/"* 

ASYNC. 


XX XXX 


7 


300.0 


10.0 




7 O 

/ .u 




1 


ASYNC. 


X X XXX 


8 


600.0 


10.0 




7 O 
/.U 


1 


1 


ASYNC. 


XX XX X 


9 


1200.0 


10.0 




7 n 
/.u 


1 


1 


ASYNC. 


X X X X 


10 


1200.0 


6.0 




4.0 




1 


ASYNC. 


X X X X 


n 


1800.0 


10 


1 


7.0 


1 


1 


ASYNC. 


X X X X 


12 


9400 


10 
1 u.u 




7 A 


1 


1 


ASYNC. 


XXX 


13 


3600 


10 
1U.U 




1 A 

7.0 


1 


1 


ASYNC. 


X X 


14 


4800.0 


10 

J U.U 


• 


a 
7.0 


1 


1 


ASYNC. 


XX 


15 


9600 


10 
1 U.U 


1 


7.0 


1 


1 


ASYNC. 


X 


16 


9000 


7 
/ .u 




6.0 


1 


— ' — 


SYNC. 


XXX 


17 


9000 O 


ft n 
o.U 




7.0 


1 


— 


SYNC. 


XXX 


18 

1 o 


9000 O 
zuuu.u 


y.u 




8.0 






SYNC. 


XXX 


19 


9400 O 
ztuu.u 


7 n 


— 


6.0 


! 


— 


SYNC. 


XXX 




9400 O 
ztuu.u 


O.U 




7.0 






SYNC. 


XXX 


21 


2400.0 


9.0 




8.0 






SYNC. 


XXX 


22 


4800.0 


7.0 




6.0 






SYNC. 


X X 


23 


4800.0 


8.0 




7.0 






SYNC. 


XX 


24 


4800.0 


9.0 




8.0 






SYNC. 


XX 


25 


9600.0 


7.0 




6.0 






SYNC. 


X 


26 


9600.0 


8.0 




7.0 






SYNC. 


x: 


27 


9600.0 


9.0 




8.0 






SYNC. 


X 


28 


40.0 


4.0 




4.0 






SYNC. 


X 


29 


16.0 


8.0 




7.0 






SYNC. 


X 


30 


40.0 


4.0 




4.0 






SYNC. 


X 
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MODEM LOSSOFCARRIER STATEMENT 
Syntax 

LOSSOFCARRIER = ►DISCONNECT 



Pragmatics 

Certain modems (Western Electric (Bell System) 103 series modems, and possibly others) maintain con- 
tinuous carrier in both directions while the line is properly connected. As such, CF (Carrier Detected) 
and CB (Clear to Send) are maintained TRUE while connected. Additionally, if each modem is equipped 
with both the Initiate Disconnect and the Respond to Disconnect options, each modem employs the 
"long space disconnect" convention. This convention allows one modem to determine if the other is 
disconnecting, and itself go "on-hook" and drop CC (Data Set Ready). 

Two problems arise, however, when only one such modem is configured at the system end, and the 
terminal is interfaced with an acoustic coupler at the terminal end. At the time of making a connection, 
establishment of carrier is difficult. In fact, the system modem may detect carrier from the coupler while 
the telephone receiver is near the coupler and before the receiver is properly seated. In this case, CF and 
CB are raised prematurely, and if the system takes this as a cue to begin transmission of a greeting, the 
two signals (the data transmitted from the system, and carrier from the acoustic coupler) interact with 
each other, and the system modem detects loss of carrier. At the time of terminating a call, if the terminal 
initiates the disconnect and has no "long space disconnect" facility, or if the terminal operator does not 
use it, the system modem detects only loss of carrier. In this case, the system modem drops CF and CB, 
the modem remains "off-hook" and maintains CC (Data Set Ready). Thereafter, any incoming calls 
would receive a "busy" signal. 

The {modem lossofcarrier statement) is implemented for such a configuration. If this statement is 
included in the definition of a modem, special logic is invoked, in addition to the normal logic, when 
dealing with that modem type. 

In the case of the system calling out, normal logic waits for CC to be raised by the modem. If CC is raised 
within 25 seconds, the line is immediately released as connected. A timeout of 25 seconds causes CD 
(Data Terminal Ready) to be dropped, the modem goes "on-hook," and the line reverts to a disconnected 
state. The special logic is invoked after CC is found TRUE. With the 25-second timeout in effect, the 
special logic then waits until CF and CB are both raised by the modem. After CF and CB are detected, 
the logic then delays approximately 5 seconds before notifying the system that the line is connected. 
This gives the terminal operator sufficient time to place the receiver in the acoustic coupler. 

In the case of a terminal-initiated disconnect, that condition is detected in the normal logic by either the 
"long space disconnect" adapter cluster interrupt or by a CC (Data Set Ready) FALSE condition. In 
addition to the normal logic, the special logic also interprets CF FALSE or CB FALSE as a terminal- 
initiated disconnect. 
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MODEM NOISEDELAY STATEMENT 
Syntax 

NOISEDELAY ► = &> ( delay time) — &~ . 

Examples 

NOISEDELAY = 0. 
NOISEDELAY = 200 MILLI. 

Semantics 

The (modem noisedelay statement) defines the amount of time that should be delayed when the modem 
enters a Clear to Send (CB) status to avoid receiving "noise" on the line, (delay time) must be expressed 
as (time) , and affects the amount of time delayed after an INITIATE RECEIVE or INITIATE TRANSMIT 
construct is executed and before the next statement is executed in a (control definition) or (request 
definition) . The (delay time) defined in this statement is used in a compiler algorithm that calculates the 
delay. The compiler algorithm is discussed in the semantics of the INITIATE RECEIVE and INITIATE 
TRANSMIT constructs under the (initiate statement) . This statement must appear in each (modem 
definition) . 
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MODEM TRANSM1TDELAY STATEMENT 
Syntax 



TRANSMITDELAY — = *~ (delay time > : • 

Examples 

TRANSMITDELAY = 0. 
TRANSMITDELAY = 1 50 MICRO. 

Semantics 

The (modem transmitdelay statement) defines the amount of time required for the modem to switch to 
a Clear to Send (CB) state after receiving a Request to Send (CA). (delay time) must be expressed as 
(rime) and affects the amount of time delayed after an INITIATE RECEIVE or INITIATE TRANSMIT 
construct is executed and before the next statement is executed in a (control definition) or (request 
definition). The (delay time) defined in this statement is used in a compiler algorithm that calculates the 
delay. The compiler algorithm is discussed in the semantics of the INITIATE RECEIVE and INITIATE 
TRANSMIT constructs of the (initiate statement). This statement must appear in each (modem definition). 
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REQUEST DEFINITION 
Syntax 

REQUEST -^(request identifier) - 



(error switch statement ) 



> (label)- 



J 



-^-(assignment statement) - 
(backspace statement) - 



» (break statement) - 

-(code statement) 

» (compound statement) - 
-(continue statement) — 

* (delay statement ) 

-(fetch statement) 

>(finish statement) 

-(fork statement) — 



. (getspace statement ) 
>(go to statement) — 
■ ( // statement ) — 



► (receive statement ) 

► (shift statement) — 
— (store statement) — 

► (sum statement) — 



.(terminate statement)- 
(transmit statement) - 
■ ( wait statement ) 



-(increment statement) — 

-(initialize statement) 

-(initiate statement) ► 

-(pause statement) - — — — e» 
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Example 

REQUEST READTTY: 

INITIATE RECEIVE. 
RECEIVE TEXT {END|. 
TERMINATE NORMAL. 

Semantics 

{request definition) s, sometimes referred to as Requests, are coded line disciplines (protocols) that are 
used in communicating with the various terminal types in the data communications network. A {request 
definition) must be coded for each capability of a terminal type; if it is possible for a terminal type to 
send input to the system and receive output from the system, then two (request definitions must be 
specified for that terminal type in its {terminal definition) . The input (request definition) is generally 
referred to as the "Receive Request," and the output {request definition) the "Transmit Request." (The 
specific {request definition) to be used for each of these capabilities is specified by the {terminal 
request statement). 

When there is a message to be sent to a particular station on a line, the {control definition) initiates 
the Transmit Request specified for the {terminal definition) associated with the station. The Transmit 
Request procedure handles the transmission of the message. If the transmission of the message is successful, 
the Transmit Request is terminated, and a branch of control is made back to the {control definition) for 
the initiation of the next Request. 

If the terminal associated with a station is allowed to input data, the {control definition) designated for 
that line normally initiates the Receive Request specified for the terminal type. If the terminal has 
information to transmit, the Receive Request procedure obtains a message space in which to store the 
received text, receives and stores the text, and then terminates in a manner that forwards the message to 
the MCS. If the terminal has nothing to transmit, the Receive Request procedure usually notes that there 
was no input, and terminates. In either case, upon termination, control returns to the {control definition) 
for the initiation of the next Request. 

{request identifier) has the syntactic form of {identifier) . 

Statements in {request definition) s are executed sequentially. In some cases, however, it is desirable 
to alter the order of execution of statements within the procedure. A {request statement) preceded by a 
(label) is one means of accomplishing this. The (go to statement) is used to transfer control to a 



A {request statement) must be appropriate for the type of Request in which it appears. That is, some 
(request statements are allowed only in Receive Requests, some are allowed only in Transmit Requests, 
and some are allowed in either type. Subsequently, the semantics portion of each statement defines, 
among other things, in which type of (request definition) the statement can appear. 
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ASSIGNMENT STATEMENT 
Syntax 

FORM I LOGICAL ASSIGNMENT 



(assignable bit variable) 



»(bit variable)- 
TRUE 



FALSE 



FORM 2 - VALUE ASSIGNMENT 



(assignable byte variable)- 



*~(byte variable)- 
•( integer)— — 



• (single character)- 



»( byte variable )- 
*( integer ) 



-*»(single character) — i 
-(translatetable identifier)-** ( -**\ byte variable ) 
Receive "address" statement] — : 



Examples 

TOG [01 = TRUE. 
TOG 1 1 ) = TOG [0] . 
LINE (BUSY) = FALSE. 
RETRY = STATION (TALLY). 

TALLY [0] = STATION (FREQUENCY) - TALLY [1 ] . 
CHARACTER = TRANSTABLEID (CHARACTER). 

STATION (TALLY) = RECEIVE ADDRESS (TRANSMIT) [ADDERR:999] . 
Semantics 
FORM 1 

This form causes the value on the right side of the equal sign to replace the current value of (assignable 
bit variable). 

FORM 2 

Value assignment causes a calculated value on the right of the equal sign to be stored in the (assignable 
byte variable). Arithmetic calculations are done in modulo 255 arithmetic. 

(assignable byte variable) = (translatetable identifier) {(byte variable)). 

This construct is the means to invoke user-defined character translation. User-defined translation is 
effected by three areas of the NDL source program. 

a. In a (translatetable definition), the programmer must define the contents of a translation 
table and associate a (translatetable identifier) with it. 
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b. In the (terminal definition) of a terminal type that requires special character translation, 
the programmer should suppress automatic character translation by using either of the 
following forms of the (terminal code statement) : 

CODE = BINARY. 

or 

CODE = EBCDIC. 

c. In a (control definition) or (request definition) , the programmer invokes the translation 
by using this option of the value assignment. Any (byte variable") can be designated as con- 
taining the character to be translated. 

The (translate table identifier) identifies the translation table to be used. An (assignable byte 
variable) is designated to the left of the equal sign, identifying where the resulting translated 
character is to be stored. 

If N is the (source size) (defined in the (translatetable definition)), then the N low-order bits 
of the (byte variable) are used as an index into the translation table. The eight-bit character 
thus indexed is stored in the (assignable byte variable). 

(assignable byte variable) = {receive "address" statement]. 

This construct attempts to RECEIVE the address characters of a terminal, and store in (assignable byte 
variable) the station index of a station whose address characters are equal to those received. The jreceive 
"address" statement} is the same as described in the semantics of the RECEIVE ADDRESS construct 
of the (receive statement) The optional syntax in the | receive "address" statement \ invokes the same 
actions as described in the (receive statement) semantics except for ADDERR. Any action specified for 
ADDERR is taken if no valid station assigned to the line is found with address characters equal to those 
received. 
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BACKSPACE STATEMENT 
Syntax 

BACKSPACE 



Semantics 

The (backspace statement) causes the message text pointer to be moved backwards one character. This 
statement can only appear in a Receive Request. The {backspace statement) may be executed repeatedly; 
however, the message text pointer will never be stepped back so far that it points into the message header. 
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BREAK STATEMENT 



Syntax 



BREAK 



* 



NULL- 



3 







( break time) 



(delay time) 



Examples 



BREAK (*, NULL). 
BREAK (200 M1LL1, 3 SEC). 
BREAK (*, 3 SEC). 
BREAK ( 100 MILLI, NULL). 

Semantics 

The (break statement) causes binary zeroes to be transmitted on the line, thus changing the state of the 
line to a "spacing" condition for a specified time. 

The (break time) specifies the (time) to break. An asterisk indicates that a standard break of 2 character 
times should be used. 

The (delay time) specifies the (time) to delay subsequent to the break and prior to when control 
continues. 
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CODE STATEMENT 
Syntax 



CODE 




ASCII - 
BINARY 



Semantics 

CODE= ASCII invokes the ASCII-to-EBCDIC translation for received data and the EBCDIC-to-ASCII 
translation for transmitted data. 

CODE=BINARY inhibits any character translation on data transmitted or received. 
Pragmatics 

The (code statement") allows a programmer to either invoke or inhibit on a logical line the DCP ASCII- 
to-EBCDIC character code translation for input, and the EBCDIC-to-ASCII character code translation 
for output. Any (terminal definition) that names, in its (terminal control statement), a (control 
definition) that utilizes the (code statement) , must define ASCII (BINARY) as its character code in 
the (terminal code statement). (Refer to the (terminal code statement) in this chapter.) 

Once that translation has been invoked on a line, the translation continues until such time that it is 
inhibited. If translation is inhibited, translation will be inhibited on that line until invoked again by any 
of the following constructs: CODE= ASCII, TERMINATE NORMAL, TERMINATE LOGICALACK, 
TERMINATE LOGIC ALACK( RETURN ) , TERMINATE ERROR, TERMINATE ENABLEINPUT, or 
(while executing a Receive Request) TERMINATE NOINPUT. 
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COMPOUND STATEMENT 
Syntax 



BEGIN 
Example 



•^request statement ) 



END 



BEGIN 

INITIATE TRANSMIT. 
TRANSMIT TEXT. 
FINISH TRANSMIT. 
END. 

Semantics 

Tlie (compound statement) groups several statements together to form a logical sequence. To execute 
more than one statement when the condition of an (if statement} is satisfied, a (compound statement) 
must be used. 
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CONTINUE STATEMENT 
Syntax 

CONTINUE 



Semantics 

The (continue statement) can appear in only those {request definition) s and (control definition) s 
written to communicate with full duplex terminal types. This statement causes the co-line to resume 
processing, if, and only if, it had been suspended by a (wait statement), or a (receive statement) with a 
CONTINUE option specified. If the co-line had not been suspended, this statement acts as a no-op. 1 lie 
(continue statement) has no effect upon the line on which it was executed. 



Pragmatics 

Refer to the (fork statement) pragmatics. 
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DELAY STATEMENT 
Syntax 

DELAY ( : (delay time) ► ) : . 

Examples 

DELAY (3 SEC). 
DELAY (0). 

Semantics 

The (delay statement) provides a means to delay a specified period of time before control proceeds to the 
next statement. The (request definition) is suspended in a "sleep" state for the (delay time) specified. 

Pragmatics 

The "sleep" state induced by the (delay statement) allows the DCP to service other logical lines. 
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ERROR— »■[ — ( switch number >— ^-]- 




P-—BREAK 



FWBUFOVFL- 



1 ^-LOSSOFCARRIER- 



PARITY 



l^-STOPBIT- 



T1MEOUT- 



Definitions 
REQUEST 
Error Switch Statement 



• {label ) 

-ABORT- 

-NULL— 



Examples 

ERROR |0| = BREAK: 0, BUFOVFL: NULL, LOSSOFCARRIER: ABORT, PARITY. 999, 

STOPBIT: 999. TIMEOUT: NULL. 
ERROR 1 1 1 = BREAK: NULL. 
ERROR 1 99] = BUFOVFL: NULL. 

Semantics 

The (error switch statement) is a non-executable statement that allows the programmer to define a set of 
default actions that are to be taken in a (receive statement) if the specified errors occur, {switch number) 
has the syntactic form of (integer) . The semantics of each option is described subsequently. 

BREAK 

The BREAK option variations cause the following actions if a break, that is, at least two character-times of 
a spacing line condition, is detected by the adapter cluster while receiving: 



BREAK: NULL 
BREAK: (label) 

BREAK: ABORT 



causes no action. Execution proceeds as if the break did not occur. 

sets TRUE the (bit variable) BREAK [RECEIVE} , and branches 
control to (label). 

sets TRUE the (bit variable) BREAK [RECEIVE] , and executes an 
implicit TERMINATE ERROR. 



BUFOVFL 

The BUFOVFL option variations cause the following actions if the DCP is unable to service a Cluster 
Attention Needed (CAN) interrupt before the adapter cluster receives another character (thus destroying 
the previous character): 



BUFOVFL: NULL 
BUFOVFL: (label) 



causes no action. Execution proceeds as if the error conditions did not 
occur. 

sets TRUE the (bit variable) BUFOVFL, and branches control to 
(label). 
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BUFOVFL ABORT sets TRUE the (bit variable) BUFOVFL, and executes an implicit 

TERMINATE ERROR. 

LOSSOFCARR1ER 

The LOSSOFCARRIER option variations cause the following actions if a loss of carrier is detected while 
receiving. 

LOSSOFCARRIER: NULL causes no action. Execution proceeds as if the error did not occur. 

LOSSOFCARRIER: (label) sets TRUE the (bit variable) LOSSOFCARRIER, and branches 

control to (label) . 

LOSSOFCARRIFR ABORT sets TRUE the (bit variable) LOSSOFCARRIER, and executes an 

implicit TERMINATE ERROR. 

There is one exception to the actions described in the above If a loss of carrier is detected while receiving, 
and if the terminal is modem-connect, and if the terminal's (station definition) references a (modem 
deflniion) that contains the statement LOSSOFCARRIER=DISCONNECT, then an implicit disconnect is 
done, regardless of the action associated with LOSSOFCARRIER in the (error action statement) . 

PARITY 

The PARITY option variations cause the following actions if a parity bit error is detected by the adapter 
cluster: 

PARITY: NULL causes no action. Execution proceeds as if the error did not occur. 

PARITY- (label) sets TRUE the (bit variable) PARITY, and branches control to 

(label) . 

PARITY • ABORT sets TRUE the (bit variable) PARITY, and executes a TERMINATE 

ERROR. 

STOPBIT 

The STOPBIT option variations cause the following actions if a stop bit error is detected by the adapter 
cluster: 

STOPBIT: NULL causes no action. Execution proceeds as if the error did not occur. 

STOPBIT- (label) sets TRUE the (bit variable) STOPBIT, and branches control to 

(label). 

STOPBIT ABORT sets TRUE the (bit variable) STOPBIT, and executes a TERMINATE 

ERROR. 

TIMEOUT 

The TIMEOUT option variations of the TIMEOUT syntax shown below cause the actions described if the 
time required to receive a character exceeds the (timeout time) . The (timeout time) » <*fuied in the 
< terminal timeout statement) , but can be overridden by including the { (timeout time) ) or (NULL) 
syntax options in the (receive statement) . 

TIMEOUT: NULL causes no action. Execution proceeds as if the error did not occur. 

TIMEOUT- (label) sets TRUE the (bit variable) TIMEOUT, and branches control to 

* X (label). 
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TIMEOUT: ABORT sets TRUE the (bit variable) TIMEOUT, and executes a TERMINATE 

ERROR. 

Pragmatics 

An (error switch statement} must be associated with a (receive statement) by means of a (switch number) 
reference before any of the default actions are invoked. The (error switch statement) can appear in a 
(request definition) as many times as the programmer deems convenient, providing the following restric- 
tion is adhered to: within a given (request definitiot*), (error switch statement) s must have a unique 
(switch number) , and all (error switch statement) s must precede all executable statements, in the 
procedure. 
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FETCH STATEMENT 



Syntax 



FETCH 




1 



(label) 



ENDOFBUFFER 



*-NULL 



Examples 



FETCH. 
FETCH [10). 

FETCH [ENDOFBUFFER:NULL]. 
Semantics 

The execution of the (fetch statement) loads into CHARACTER, the character pointed to by the message 
text pointer and updates the pointer to point forward one character position. 

When using the (fetch statement), provision should be made for taking action if the end-of-the-text buffer 
is encountered, the programmer can specify this action by including the optional syntax shown in the 
syntax diagram. 

NULL specifies that no action should be taken. 

(label) specifies that control should branch to (label) if the end of buffer is encountered. 

If the end of buffer is encountered and no action is specified, an implicit TERMINATE ERROR is 

executed. 

For program documentation , the ENDOFBUFFER syntax can be added to the error action 
specification. 

Supplementary Example 

INITIATE TRANSMIT. 
3: FETCH [ENDOFBUFFER:5J. 

TRANSMIT CHAR. 

GO TO 3. 
5: FINISH TRANSMIT. 
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FINISH STATEMENT 
Syntax 

FINISH ^TRANSMIT 



NULL- 



< delay time ) 



Examples 

FINISH TRANSMIT. 
FINISH TRANSMIT (NULL). 
FINISH TRANSMIT (3 SEC). 

Semantics 

The purpose of the (finish statement) is to take a line out of the transmit ready state and prepare the line 
to receive information. The adapter cluster delays a period of time long enough for the last character 
TRANSMITted to be transmitted, plus 2 milliseconds, before the line is put in a receive ready state. Al- 
though the (finish statement) puts the line in a receive ready state, the cluster hardware invokes a delay 
that inhibits any data from being received for 25 milliseconds. An INITIATE RECEIVE construct should 
precede any subsequent (receive statement) to override the 25-millisecond hardware delay. 

The (delay time) option allows the programmer to specify a software delay of (time) before execution 
proceeds in the (control definition). 

For example, the statement 

FINISH TRANSMIT (3 SEC). 

is equivalent to 



FINISH TRANSMIT. 
DELAY (3 SEC). 



The FINISH TRANSMIT (NULL) form is equivalent to FINISH TRANSMIT. 
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FORK STATEMENT 
Syntax 

FORK — label > 



Example 

FORK 10. 
Semantics 

The {fork statement) is allowed in only those (control definition) s and (request definition) s 
that are written to communicate with full duplex terminal types. This statement can be executed in the 
(control definition) or (request definition) of the auxiliary line or the primary line. The execution of 
this statement causes the co-line control, if not busy, to branch to and begin executing code in the (request 
definition) that executes the FORK at the (lab el) specified, while control on the FORKing line executes 
an implicit PAUSE (i.e., a (pause statement)) and continues executing in parallel. The co-line is deter- 
mined busy or not busy by testing the BUSY bit (i.e., LINE(BUSY) or AUX(LINE(BUSY)), whichever is 
appropriate). If the co-line is busy, the (fork statement) acts as a no-op. 

Pragmatics 

Synchronization problems can occur between the primary and auxiliary lines as a result of the (fork 
statement) executing the implicit PAUSE. The implicit PAUSE yields use of the DCP, to allow processing to 
to proceed on other lines. Thus, processing on the co-line is actually started before the FORKing line 
exits the (fork statement) . As a result, the programmer must, by some means (e.g., by setting and testing 
line TOGs), effect the synchronization of the lines. This is especially critical if the code contains (wait 
statements and (continue statements. The following example illustrates how full duplex lines could 
"hang" as a result of poor synchronization. 

FORK 10. 
WAIT. 



10: CONTINUE. 
WAIT. 



Assume that the primary line executes the FORK 10. At that point, the primary line temporarily yields 
use of the DCP to other lines. The auxiliary line starts up and executes the CONTINUE. Since primary 
control is still at the (fork statement) and is not in a (wait statement) , the auxiliary line CONTINUE acts 
as a no-op. Next, the auxiliary line executes the WAIT: When the primary line gets use of the processor 
again, it executes its WAIT. At this point, the primary and auxiliary lines are "hung", each WAITing for a 
CONTINUE from its co-line. 
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GETSPACE STATEMENT 
Syntax 

GETSPACE ►[ label > » ]— — 

Example 

GETSPACE [10] 
Semantics 

The (getspace statement) provides the means for a Receive Request to explicitly acquire a message space 
for input. The message space (if obtained) is linked into the head of the Station Queue, thereby setting 
STATION (QUEUED) to TRUE. If there is no message space available at the time the (getspace 
statement) is executed, control branches to the (label). If a message space has already been acquired, this 
instruction acts as a no-op. This statement is also treated as a no-op if it appears in a Transmit Request. 
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GO TO STATEMENT 



Syntax 



GO 




»- (label) 



(byte variable) 



□ 



(label) 



) 



Examples 



GO 10. 
GOTO 10 

GO TO TOGS, (0,1,2,3). 
GO TO STATION (5,9,12). 

Semantics 

The (go to statement) alters the path of control, that is, the sequential flow of statement execution, 
within a (request definition). 

GOTO (label) 

This form of the (go to statement) unconditionally transfers control to the (label) specified. 
GO TO (byte variably ... 

This form of the (go to statement) provides a convenient means of dynamically selecting one or more 
(label) s to which control could branch. The (label) to branch to is selected by using the (byte variable) 
as an index value. 1 1* N represents the number of (label)s in the (go to statement) , then the (label) s are 
numbered to N-l . The (label) corresponding to the index value is the (label) to which control branches. 
If the index value is greater than N-l , then control continues at the statement following the (go to 
statement) . 

Supplementary Example 

GO TO STATION (5,9,12). 

% EXECUTION CONTINUES HERE IF STATION >2. 



5: TOG [01 = TRUE. 



9: TOG [I] = TRUE. 



12: TOG [2] = TRUE. 
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This example illustrates the GO TO (byte variable) construct of the (go to statement). The value of 
STATION determines the next statement to be executed. If the value of STATION is 0, control branches 
to the (label) 5; if the value of STATION is 1, control branches to (label) 9; and if the value of STATION 
is 2, control branches to (label) 12. If the value of STATION is greater than 2» control continues at the 
next sequential statement. 
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IF STATEMENT 
Syntax 



IF 



•*NOT-^ 



«*TRUE- j 

•►FALSE 

(bit variable)** 
•(byte variable) 
'(integer) 



•(single character) -9» 



» LSS 
-LEO 
"EQL-^ 
*NEQ-«* 
*CEQ-«* 
"•CTR *•* 



>(hyte variable)- 
-+»(integer) 



^(single character)-** 



-THEN- 



^(request statement)' 



71 f 

—I * El.SE •^■(request statement)! 



Examples 

IF TRUE THEN. 

IF TOG [0] THEN TOG [0] » FALSE. 

IF TALLY [0] LSS TALLY [1] THEN TALLY [0] = TALLY [1]. 

IF CHARACTER = 4"FF" THEN 

INITIATE BREAK. 
ELSE 

BEGIN 

CHAR > 4"00". 
GO TOO. 
END. 

Semantics t 

The {if statement) causes a condition (i.e., a Boolean expression) to be evaluated. The subsequent path 
of program control depends on whether the condition is evaluated as TRUE or FALSE. 

If the condition is TRUE, the {request statement) following the THEN, if present, is executed. Program 
control then resumes at the statement that follows the (if statement) . 

If the condition is FALSE, the (request statement) following the ELSE is executed or, if the ELSE 
(request statement) is omitted, program control resumes at the {request statement) following the 
{if statement) . 

The {request statement) can be any legal {request statement)* including the (if statement) and 
(compound statement). 

The meanings of the relational operators are contained in table 5-5. 
The following diagrams illustrate the above semantics. 
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The following diagrams illustrate the above semantics. 



| TRUE ^ ! } 

IF {condition } THEN (request statement) (request statement) 



I ' x 'J 

I FALSE 7 



-TRUE 



1 I " ' } 

IF { condition ( THEN (request statement) ELSE (request statement) (request statement) 

L— -FALSE 7 ' — 



Table 5-5. Relational Operators 



RELATIONAL OPERATOR 


MEANING 


SYNONYMS 


LSS 


Less than 


< and LS 


LEQ 


Less than or 
equal to 


LE 


EQL £./ 


Equal to 


= an'dEQ 


NEQ 


Not equal to 


NE 


GEQ 


Greater than 
or equal to 


GE 


5 GTR 


Greater than 


> and GT 
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INCREMENT STATEMENT 
Syntax 



INCREMENT y-^-TR AN 



SEQUENCE 



SEQERR- 



NULL- 

-(label)- 



Examples 

INCREMENT TRAN. 

INCREMENT SEQUENCE [SEQERR: 10] . 

INCREMENT SEQUENCE [NULL] . 

Semantics 

INCREMENT TRAN 

This construe! of the (increment statement) is only allowed in those (request definitions in the 
{terminal request statement) s of (terminal definition) s that contain a (terminal transmission number 
length statement) defining the transmission number length as nonzero and non-NULL. 

INCREMENT TRAN causes I to be added to the receive transmission number stored in the Station 
Table when it is executed in a Receive Request, and causes 1 to be added to the transmit transmission 
number stored in the Station Table when it is executed in a Transmit Request. 

The transmission numbers are stored and incremented in EBCDIC. 

If INCREMENT TRAN causes the transmission number to exceed (overflow) the size of the transmission 
number field, the carry is truncated and the result will be zeros (i.e., EBCDIC zeros) in that field. 

INCREMENT SEQUENCE 

This construct causes the sequence number stored in the DCP Station Table to be increased by the value 
of the increment: (also stored in the DCP Station Table), providing that the station is in "sequence 
mode"; otherwise, this statement is a no-op. 

When using the INCREMENT SEQUENCE construct, provision should be made for taking action if the 
increment caused the sequence number to exceed (overflow) the size of the sequence number field. The 
programmer can take such action by including the optional syntax. Failure to include overflow action 
results in an implicit TERMIN ATE ERROR if an overflow occurs. 

SEQERR: NULL and NULL are semantically equivalent. These options set the SEQERR {bit variable) 
TRUE, and control continues at the next sequential instruction. 

SEQERR: (label) and <to&e/)are semantically equivalent. They cause the SEQERR (bit variable) to be 
set TRUE, and control to branch to (label). 

Regardless of whether error action is specified or not, an overflow of the sequence number field destroys 
the contents of that field. 
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Pragmatics 

A station is considered to be in sequence mode whenever its SEQUENCE (bit variable) is TRUE. 
SEQUENCE can be set TRUE only as a result of the Message Control System (MCS) executing the SET/ 
RESET SEQUENCE MODE (TYPE = 49) DCWRITE. In addition, the TYPE 49 DC WRITE also stores 
the starting sequence number and increment in the appropriate fields of the DCP Station Table. 

Sequence mode can be used for any application that the NDL programmer may see fit. Its use, however, 
requires common conventions between the NDL programmer and the MCS programmer. Burroughs 
has utilized sequence mode constructs in two (request definition's of SYMBOL/SOURCENDL: 
READTELETYPE and WRITETELETYPE. Both require the cooperation of SYSTEM/CANDE to effect 
the execution of those statements. The reader is referred to those (request definition's as an example 
of a particular application that Burroughs has implemented. 
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INITIALIZE STATEMENT 



Syntax 
INITIALIZE 



BCC- 
CRC 



> RETRY- 
-TEXT — 
-TRAN- 



• TALLY — »-[ — — s»(tally number) <»■ ] 

■TOG [ *■» (toggle number) •» ] 



Examples 

INITIALIZE BCC. 
INITIALIZE CRC. 
INITIALIZE RETRY. 

Semantics 

INITIALIZE BCC 

This construct causes the (byte variable) BCC to be initialized for purposes of accumulating a Block Check 
Character. The value to which BCC is initialized is dependent upon the horizontal parity defined for the 
station's associated (terminal definition) (in the (terminal definition parity statement)). If horizontal 
parity is defined as HORIZONTAL:ODD, then BCC is initialized to all ones (i.e., 4"FF"). If defined as 
HORIZONTAL : EVEN , then INITIALIZE BCC initializes BCC to all zeros (i.e., 4"00"). 

INITIALIZE CRC 

This instruction initializes CRC to the initial value required for calculating the Cyclic Redundancy Check. 
Any (terminal definition) referencing a (request definition^ (in the (terminal request statement) ) 
that contains this instruction must define the horizontal parity (in the (terminal parity statement)) as 
HORIZONTAL:CRC(l 6); otherwise a syntax error is generated. 

INITIALIZE RETRY 

This instruction causes the value stored in DCP INITIALRETRY to be stored DCP RETRY. 
INITIALIZE TEXT 

The function of this form is to initialize the message text pointer to zero. When initialized to zero, the 
message text pointer points to the first text character of the message. 
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INITIALIZE TRAN 

This form causes zeroes (i.e., EBCDIC zeroes, 4"F0F0F0") to be stored in the appropriate Transmission 
Number fields of the Station Table. In a Receive Request, zeroes are stored in the Receive Transmission 
Number field; in a Transmit Request, zeroes are stored in the Transmit Transmission Number field. 

INITIALIZE TALLY [ (tally number) ] 

This form causes the specified station TALLY to be initialized from the appropriate message header field 
if a message is present ; otherwise the specified TALLY is initialized to zero. 

INITIALIZE TOG [ (toggle number) ] 

This form causes the specified station TOGGLE to be initialized from the appropriate message field if 
a message is present ; otherwise the specified TOGGLE is initialized FALSE. 
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INITIATE STATEMENT 
Syntax 



INITIATE- 



RECEIVE 



-^TRANSMIT- 



•NULL- 



-(delay time)- 



■+* BREAK 



Examples 

INITIATE RECEIVE. 
INITIATE TRANSMIT (3 SEC). 
INITIATE BREAK. 

Semantics 

INITIATE RECEIVE 

The INITIATE RECEIVE construct causes the adapter cluster to initiate a receive delay calculated for the 
station. After the delay, the hardware is ready to receive information. 

The amount of time delayed, referred to as the Initiate Receive delay, is unique to each station and is 
calculated at compile-time for each station. The algorithm that the compiler uses to calculate the Initiate 
Receive delay is described in the following three paragraphs. 

a If the (modem definition) referenced in the (station definition) (in the (station modem statement ) 
defines the modem NOISEDELAY as being greater than zero, then the Initiate Receive delay is 
2 milliseconds less than the combined (time)s defined in the (modem noisedelay statement) and 
the (modem transmitdelay statement) . 

b. If the modem NOISEDELAY is defined as zero and the modem TRANSMITDELAY is defined as 
being less than 7 milliseconds, then the Initiate Receive delay is zero. 

c. If the modem NOISEDELAY is defined as zero and the modem TRANSMITDELAY is defined as 
being equal to or greater than 7 milliseconds, then the Initiate Receive delay is the lesser of 15 
milliseconds or 

(1.5 milliseconds + modem TRANSMITDELAY). 

The NULL option or the (delay time) option can be used to override the calculated Initiate Receive delay. 
NULL immediately readies the hardware so that it can receive information, (delay time) specifies a (time) 
to be used in place of the Initiate Receive delay. 

Pragmatics ' 

An INITIATE RECEIVE instruction should precede the first (receive statement) following a transmission. 
If it does not, there is a possibility that execution of the (receive statement) will be delayed for a period 
of time of up to 25 milliseconds. The cause of the 25-millisecond delay is described under the semantics 
of the (finish statement). 
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INITIATE TRANSMIT 

The INITIATE TRANSMITconstruct causes the adapter cluster to be put in a transmit state after a calcu- 
lated delay. The amount of time delayed is referred to as the Initiate Transmit Delay, and is unique to 
each station. It is derived by taking the greater of the NOISEDELAY {time) specified for the modem 
configured at the system end, or the TURNAROUND (time) specified by the station's (terminal 
definition) . 

This construct must be executed prior to any attempt to TRANSMIT. 

The NULL option or the (delay time) option can be used to override the calculated Initiate Transmit ^ 
delay. NULL causes the adapter cluster to be put in a transmit state immediately, (delay time) specifies 
a (time) to be used in place of the Initiate Transmit delay. 

INITIATE BREAK 

The INITIATE BREAK construct causes binary zeroes to be transmitted on the line, thus changing the 
state of the line to a "spacing" condition. The line remains in the spacing condition until some subsequent 
instruction causes the adapter cluster to change the state of the line. Constructs that would change the 
line's state are INITIATE TRANSMIT, INITIATE RECEIVE, FINISH TRANSMIT, BREAK and IDLE. 
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PAUSE STATEMENT. 
Syntax 



PAUSE 



Semantics 

The (pause statement) suspends the {request definition) in a "sleep" state for a minimum period of 
time (200 microseconds for the B 6358 Model II DCP, and 6 microseconds for the B 6350 Model I DCP) 
to allow the DCP to service other lines. It is recommended that a {pause statement) be used in any kind 
of loop that would tie up processor time and thereby prevent the servicing of other lines. The failure to 
do so results in a high number of timeout faults. 

Pragmatics 

Instances may occur in which the DCP requires an even greater period of "sleep" to service other lines. 
Repeated timeout faults, despite utilization of the {pause statement), are indications of such conditions. 
A greater period of "sleep" time can be effected by means of a {delay statement), with the {delay time) 
specified greater than "sleep" time effected by the {pause statement). 
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RECEIVE STATEMENT 
Syntax 



CNUIL - -^0 
^timeout //>//(*) J 



-►ADDRESS- 



**BCC 



^Ct** receive 
u» transmit j 



J 



♦►CHARACTER 
-►CRC- 



♦-TEXT - 
► TRAN - 



. (string) - 



YT\^ERROR-^[-^< vh '^' number)-**] 

^(switch number)- — : — 

-►ADDERR 



-►BACKSPACE - 

-► BCCERR 

-►BREAK 



-► BUFOVFL — 
-►CONTINUE - 
-► CONTROL - 
-►CRCERR — 
-►END 



-► ENDOFBUFFER - 
-►FORMATERR — 
► LINIDIXETi: — 



-► LOSSOFC AR RI ER -► 
► PARITY — 



-►STOPBIT- 



-►TIMEOUT- 



-►TRANERR 

•►WRU— 

■^(single character)- 



~T 

[•-NULL-*- 
I*. ABORT— 



Examples 



RECEIVE. 

RECEIVE CHARACTER. 

RECEIVE (3 SEC) ADDRESS (RECEIVE) [0, ADDERR: 10], 
RECEIVE (NULL) [ 

PARITY :999, 
LOSSOFCARRIER:999, 
BACKSPACE :NULL, 
END, 

WRU.NULL 
1. 

RECEIVE CRC [ERROR [1 ] , CRCERR:10] . 
RECEIVE "LITERAL STRING" [FORMATERR :NULL] . 
RECEIVE EOT SOH. 
RECEIVE TEXT IEND: 101 . 
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Semantics 

The (receive statement) causes the adapter cluster to attempt to receive information from the appropriate 
logical line. 

The following two syntax items define a maximum amount of time that the adapter cluster should wait 
for receipt of the first character, and then each subsequent character, if applicable, before assuming that 
the terminal lias "timed out." If neither of these options is included, the {timeout time) defined 
(in the (terminal timeout statement) ) for the station's associated terminal type is implicitly used as 
the (timeout time) in this statement. 

(NULL) 

This option specifies that the adapter cluster should wait an infinite amount of time. 
( (timeout time) ) 

The (timeout time) defines a (time) that the adapter cluster should wait for a character. If this (rime) 
is exceeded before receipt of a character, and the TIMEOUT syntax appears, then the action specified for 
TIMEOUT is taken (refer to TIMEOUT). If the (timeout time) is exceeded and TIMEOUT syntax 
does not appear, an implicit TERMINATE ERROR is executed. 

The following syntax options define the nature of the information to be received, the amount of 
information to be received, and how the information is to be handled. If none of the options are used, it 
is semantieally equivalent to specifying CHARACTER (e.g., "RECEIVE." is semantically equivalent to 
"RECEIVE CHARACTER.") . 

ADDRESS 

The' proper number of address characters (as defined by the station's associated (terminal definition) 
in the (terminal address size statement)) are received and checked for agreement against the actual 
address characters defined in the (station address statement). If the address characters do not correspond, 
an address error condition results; if the ADDERR syntax appears, then the specified action is taken. Other- 
wise an implicit TERMINATE ERROR is executed. (Refer to the ADDERR semantics.) 

ADDRESS (RECEIVE) 

This option is equivalent to ADDRESS, except that ADDRESS (RECEIVE) must be used when an address 
pair is defined in the (station address statement) and the programmer needs to check for the proper 
receive address. 

ADDRESS (TRANSMIT) 

This option is equivalent to ADDRESS, except that ADDRESS (TRANSMIT) must be used when an 
address pair is defined in the (station address statement) and the programmer needs to check for the proper 
transmit address. 

BCC 

One character is received and checked against the (byte variable) BCC. If the character received and 
BCC are not equal, a Block Check Character error condition results; if the BCCERR syntax appears, 
then the specified action is taken. Otherwise an implicit TERMINATE ERROR is executed. 

Presumably, if the RECEIVE BCC construct appears, the programmer has defined horizontal parity in 
the (terminal parity statement) , and the accumulated Block Check Character is contained in BCC. 
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CHARACTER 

One character is received and stored in CHARACTER. 
CRC 

Two characters are received. The first character is checked against CRC [0] , and the second compared 
S ns CRC [1 1 If the characters received and CRC are not equal, a Cyclic Redundancy ChecMrror , 
condition results; if the CRCERR syntax appears, then specified action is taken. Otherwise an implicit 
TERMINATE ERROR is executed. 

Presumably if the RECEIVE CRC instruction appears, the programmer has defined horizontal parity 
as HORIZONTAL:CRC(16) in the (terminal parity statement) , and the Cyclic Redundancy Check is 
contained in CRC [0] and CRC [1] . 

TEXT 

Characters are received into CHARACTER and stored in the text portion of the message space obtained 
until either a syntax option results in a branch from the (receive statement) or a non-recoverable error, 
such as a disconnect, occurs. If the occurrence of a particular character results in a branch outside of the 
(receive statement) (as specified by a syntax option), then that character is not stored but remains in 
CHARACTER. 

The RECEIVE TEXT construct is, in effect, the same as the following loop: 

I : RECEIVE CHARACTER 
STORE CHARACTER 
(JOTOl. 

In nearly all cases, the (receive statement) should contain optional syntax to avoid the "endless" loop 
and an eventual implicit TERMINATE ERROR as a result of a timeout, end-ot-buffer condition, etc. 

TRAN 

The proper number of transmission number characters (as defined by the station's ^^<<™™l 
definition) in the (terminal transmission number length statement)) are received and checked for agree- 
mtnt S the Receive Transmission Number maintained in the DCP Station Table. If the character* _ 
received and the Receive Transmission Number are not equal a transmission ^ 
TRANERR syntax appears, then specified action is taken; otherwise an implicit TERMINATE ERROR 
is executed. 

(string) 

The number of characters as indicated by the length of the (string) are received and checked against thost 
characters in the (string. If the (string) and the characters received are not equal, then a format error 
condition results. If the FORMATERR syntax option appears, then that action is taken; otherwise an 
implicit TERMINATE ERROR is executed. 

The following syntax options specify actions to be taken upon either the receipt of defined characters 
or occurrences of specific error conditions. 
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ERROR [ (switch number) ] 

This syntax option associates a previously denned Error Switch with the (receive statement). This allows 
the programmer to associate a set of previously defined error actions with the (receive statement) , thus 
reducing the amount of coding required for each (receive statement). BREAK, BUFOVFU 
LOSSOFCARRIER, PARITY, STOPBIT, and TIMEOUT syntax options are not allowed if the ERROR 
f (switch number) J syntax appears in the (receive statement) . Refer to the (error switch statement) 
for more information. 

(switch number) - 

Semantically equivalent to ERROR [(switch number) ] . 

ADDERR 

The ADDERR option variations cause the following actions if an address error is detected when an attempt 
is made to receive a terminal's address characters: 

ADDERR sets TRUE the ADDERR (bit variable) and 

branches control to the next sequential 
statement. 

ADDERRiNULL causes no action. Execution proceeds as if the 

error condition did not occur. 

ADDERR: (label) sets TRUE the ADDERR (hit variable) and 

branches control to (label). 

ADDERR: ABORT not allowed 

BACKSPACE 

The following BACKSPACE option variations cause the following actions if the terminal's backspace 
character (as defined by the (terminal backspace character statement)) is recvw 

BACKSPACE moves the message text pointer backwards one 

character position, and branches control to the 
next sequential statement. 

BACKSPACE:NULL moves the message text pointer backwards one 

character. Control remains within the (receive 
statement) if of the form RECEIVE TEXT. 

BACKSPACE: (label) moves the message text pointer backwards one 

character, and branches control to (label). 

BACKSPACE: ABORT not allowed. 

BCCERR 

The following BCCERR option variations cause the following actions if the character received is not equal to 
the data stored in BCC. 

BCCERR sets TRUE the (bit variable) BCCERR, and 

branches control to the next sequential 
statement. 

BCCERR:NULL causes no action. Execution proceeds as if the 

error condition did not occur, 



5-112 



Definitions 
REQUEST 
Receive Statement - Continued 



sets TRUE the (bit variable) BCCERR and 
branches control to (label) . 

BCCERR: ABORT not allowed, 

BREAK 

The BREAK option variations cause the following actions as if a break, that is, at least two character-times 
of a spacing line condition, is detected by the adapter cluster while receiving: 

sets TRUE the (bit variable) BREAK 
[RECEIVE! , and branches control to the next 
sequential statement. 

causes no action. Execution proceeds as if the 
break did not occur. 

sets TRUE the (bit variable) BREAK 
[RECEIVE] , and branches control to (label). 

sets TRUE the (pit variable) BREAK 
[RECEIVE] , and executes an implicit 
TERMINATE ERROR, 

BUFOVFL 

The following variations of the BUFOVFL option cause the following actions if the DCP is unable to service 
a Cluster Attention Needed (CAN) interrupt before the Adapter Cluster receives another character (thus 
destroying the previous character): 

BUFOVFL sets TRUE the (pit variable) BUFOVFL, and 

branches control to the next sequential 
statement. 

BUFOVFL: NULL causes no action. Execution proceeds as if the 

error condition did not occur. 

BUFOVFL: (label) sets TRUE the {bit variable) BUFOVFL, and 

branches control to (label). 

BUFOVFL: ABORT sets TRUE the (bit variable) BUFOVFL, and 

executes an implicit TERMINATE ERROR. 

CONTINUE 

This item is allowed only in {receive statement)* of (control definition) s and {request definition) s that are 
written to communicate with full duplex terminal types. CONTINUE syntax causes action as described 
below if the co-line executes a (continue statement) before all information specified by the Receive 
statement) is received. 

CONTINUE branches control to the next sequential 

statement 

causes no action. Execution proceeds as if the 
(fontinue statement) had not been executed. 

branches control to (label). 

CONTINUE-ABORT not allowed. 



BCCERR : (label) 



BREAK 

BREAK: NULL 
BREAK: (label) 
BREAK:ABORT 



CONTINUE:NULL 
CONTINUE: (Jabel) 
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CONTROL 

The following variations of the CONTROL option cause the following actions if the control character of 
the station ( as defined in the (station control character statement) ) is received : 

CONTROL sets TRUE the (bit variable) CONTROLFLAG, 

and branches control to the next sequential 
statement. 

CONTROL:NULL sets TRUE the (bit variable) CONTROL FLAG, 

and execution continues if the character was 
not the station's control character. 

CONTROL: (label) sets TRUE the {bit variable) CONTROLFLAG, 

and branches control to (label). 

CONTROL: ABORT not allowed 

CRCERR 

The following variations of the CRCERR option cause the following actions if the first character received 
does not equal CRC [0] , or the second character received does not equal CRC [1] . 
(This item is appropriate only for the RECEIVE CRC construct of the (receive statement) ; refer to the 
CRC option.) 

CRCERR sets TR UK the (bit variable) CRCERR, and 

branches control to the next sequential statement. 

CRCERR:NULL cause no action. Execution proceeds as if the 

error did not occlirr: 

CRCERR: {label) sets TRUE the variable) CRCERR, and 

branches control to (label). 

CRCERR:ABORT not allowed. 

END 

The following variations of the END option cause the following actions if the "end" character of the 
station (as defined by the (terminal end character statement), in the {terminal definition) associated 
with the station) is receivea: 

END causes control to branch to the next sequential 

statement. 

END:NULL causes no action; Execution proceeds as if the 

character was not the "end** character. 

END: {label) branches control to {label). 

END: ABORT not allowed. 
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ENDOFBUFFER 

This syntax ileni is allowed in the RECEIVE TEXT contruet of the (receive statetnent) . The variations of 
the ENDOFBUFFER option shown below cause the following actions if either of the following conditions 
arises: 

a. There is no message space and ail attempt is made to store information into a message 
space (the store function is an implicit action of the RECEIVE TEXT construct), or 

b The number of characters stored in the message exceeds the maximum allowed (the 
maximum is defined by either the germinal maxinput statement) or the (terminal 
buffer size statement) ). 

ENDOFBUFFER sets TRUE the (bit variable) ENDOFBUFFER, 

and branches control to the next sequential 
statement. 

ENDOFBUFFER :NULL causes no action. Execution proceeds as if the 

error did not occur. 

ENDOFBUFFER: (label) sets TRUE the (bit variable) ENDOFBUFFER, 

and branches control to (label). 

ENDOFBUFFER: ABORT not allowed. 

FORMATERR 

The following variations of the FORMATERR option cause the following actions if the characters received 
are not equal to those in the (string) (this item is appropriate only for the RECEIVE (string) construct 
of the (receive statement)): 

FORMATERR sets TRUE the (bit variable) FORMATERR, 

and branches control to the next sequential 
statement. 

FORMATERR :NULL causes no action. Execution proceeds as if the 

error did not occur. 

FORMATERR: (label) sets TRUE the (bit variable) FORMATERR, 

and branches control to (label). 

FORMATERR:ABORT not allowed. 

UNEDELETE 

The following variations of the LINE DELETE option cause the following actions if the station's 
linedelete character is received (the LINEDELETE character is defined by the (terminal linedelete 
character statement)): ■ 

LINEDELETE alters the value of the message text pointer to 

point to the first character position in the message 
text, and branches control to the next sequential 
istatement. 

LINEDELETE:NULL alters the value of the message text pointer to 

point to the first character position in the message 
text, and execution proceeds as if the character 
Was not the linedelete character. 
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LINEDELETE: (label) alters the value of the message text pointer to 

point to the first character position in the message 
text, a ml branches control to (label). 

LIN EDELETE: ABORT not allowed. 

LOSSOFCARRIER 

The following variations of the LOSSOFCARRIER syntax cause the following actions if a loss of carrier 
is detected while receiving. 

LOSSOFCARRIER sets TRUE the (bit variable) LOSSOFCARRIER, 

and branches control to the next sequential 
statement. 

LOSSOFCARRIER :NULL causes no action. Execution proceeds as if the 

error did not occur. 

LOSSOFCARRIER: (label) sets TRUE the (bit variable) LOSSOFCARRIER, 

and branches control to (label). 

LOSSOFCARRIER: ABORT sets TRUE the (bit variable) LOSSOFCARRIER, 

and executes an implicit TERMINATE ERROR. 

There is one exception to the actions described above. If a loss of carrier is detected while receiving, and 

if the terminal is modem-connect, and if the terminal's (station definition) references a (modem definition) 

that contains the construct LOSSOFCARRIER=DISCONNECT, then an implicit disconnect is done, w' 

regardless of the action specified. 

PARITY 

The following variations of the PARITY option cause the following actions if a parity bit error is detected 
by the adapter cluster: 

PARITY sets TRUE the (bit variable) PARITY, and 

branches control to the next sequential state- 
ment. 

PARITY :NULL causes no action. Execution proceeds as if the 

error did not occur. 

PARITY: (label) sets TRUE the (bit variable) PARITY, and 

branches control to (label) . 

PARITY: ABORT sets TRUE the (bit variable) PARITY, and 

executes a TERMINATE ERROR. 

STOPBIT 

The following variations of the PARITY option cause the described actions if a stop bit error is detected 
by the adapter cluster: 

STOPBIT sets TRUE the (bit variable) , and branches control 

to the next sequential statement. _ 

STOPBIT:NULL causes no action. Execution proceeds as if the W 

error did not occur. 
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sets TRUE the (bit variable) STOPBIT, and 
branches control to (label). 

sets TRUE the (bit variable) STOPBIT, and 
executes a TERMINATE ERROR. 



TIMEOUT 



The variations of the TIMEOUT syntax shown below cause the actions described if the time required to 
receive a character exceeds the (timeout time). The (timeout time) is defined in the (terminal timeout 
statement) , but can be overridden by including the ((timeout time) ) or (NULL) syntax options in the 
(receive statement) . 

TIMEOUT sets the (bit variable) TIMEOUT, and branches 

control to the next sequential statement. 



TIMEOUT:NULL 



TIMEOUT: (label) 



TIMEOUTrABORT 



causes no action. Execution proceeds as if the 
error did not occur. 

sets TRUE the (bit variable) TIMEOUT, and 
branches control to (label). 

sets TRUE the (bit variable) TIMEOUT, and 
executes a TERMINATE ERROR. 



TRANERR 



The following variations of the TRANERR option cause the described actions if the characters received 
and the Receive Transmission Number stored in the Station Table are not equal (this item is allowed only 
in the RECEIVE TRAN construct of the (receive statement)): 

TRANERR 



TRANERRNULL 



TRANERR: (label) 



TRANERR:ABORT 



sets TRUE the (pit variable) TRANERR, and 
branches control to the next sequential state- 
ment. 

causes no action. Execution proceeds as if the 
error did not occur. 

sets TRUE the (bit variable) TRANERR, and 
branches control to (Jabel). 

not allowed. 



WRU 



The following variations of the WRU syntax cause the following actions if the WRU character of the 
station is received (the (sfa/tort WW C/ c/wwrt^ 



WRU 



WRU:NULL 



WRU: (label) 



WRU: ABORT 



sets TRUE the WRU (bit variable) , and branches 
control to the next sequential, statement. 

sets TRUE the WRU (bit variable) , and execution 
proceeds as if the character received was not the 
WRU character. 

sets TRUE the (bit variable) WRU, and branches 
control to Qabel). 

not allowed. 
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(single character) 

The following variations of the (single character) syntax cause the following actions if a character received 
is equal to the single character : 

(single character) branches control to the next sequential state- 

ment. 

(single character^NVLL causes no action. Execution proceeds as if the 

character received was not equal to the (single 
character). 

(single character): (label) branches control to (label), 

(single character) : ABORT not allowed. 

The allowable combinations of the (receive statement) syntax options are defined in table 5-6 below. 
The (NULL) and ( (timeout time) ) options are allowed in any construct of the (receive statement} . 
Allowed combinations of the other syntax options are denoted by a "X" in the appropriate columns 
and rows. 

Table 5-6. Allowable Combinations for (receive statement) 





ADDERR 

BACKSPACE 

BCCERR 

BREAK 

BUFOVFL 

CONTINUE 

CONTROL 

CRCERR v 

END 

ENDOFBUFFER 

FORMATERR 

LINEDELETE 

LOSSOFCARRIER 

PARITY 

STOPBIT 

TIMEOUT 

TRANERR 

WRU 

(single character} 


ADDRESS 

ADDRESS( RECEIVE) 

ADDRESS(TRANSMIT) 

BCC 

CHARACTER 
CRC 
TEXT 
TRAN 

(stringy 


X X X X X X X X 
X X X X XXX X 
X XXX X X X X 
XXX X XXX X 
X XXX X X XXXXX XX 

XXX X X X X X 
XXXXX XX XXXXX XX 
X X X X X X X X 
XXX X X X X X 
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Supplementary Examples 

Statement 
RECEIVE (3 SEC) [TIMEOUT: 10] . 



RECEIVE ADDRESS [ADDERR:99[. 



RECEIVE CHARACTER [CONTINUE: 10, 

CONTROL:20, 
T1MEOUT:30, 
' 4 *":40J. 



RECEIVE [ERROR[0]1. 



RECEIVE [0] . 



RECEIVE (1 SEC) TEXT [ LINEDELETE :NULL, 

CONTROL :NULL] . 



Explanation 

Causes the adapter cluster to attempt to receive a 
character. If the character is not received within 
3 seconds, the {bit variable) TIMEOUT is set 
TRUE and control branches to 10. 

If the character(s) received do not equal those 
defined in the (station address statement) , the- 
{bit variable) ADDERR is set TRUE, and control 
branches to 99. 

This statement would only be allowed in a 
{control definition) ox {request definition) that 
is written to communicate with full duplex 
terminal types, because it contains the CONTINUE 
item. 

CONTINUE: 10 would cause a branch to 10 if the 
co-line (control definition) executes a {continue 
statement) before a character is received. 

CONTROL:20 would set CONTROLFLAG TRUE 

and branch to 20 if the character received is the 
station's control character. 

TIMEOUT :30 would set TIMEOUT TRUE and 

branch to 30 if a character is not received within 
the {timeout time) defined in the {terminal 
timeout statement) . 

"*":40 would cause a branch to 40 if the 
character received is the asterisk character. 

An attempt is made to receive one character and 
store it in CHARACTER, If any errors described 
in the associated (error switch statement) occur 
while receiving, then the action defined in that 
{error switch statement) is taken. 

An attempt is made to receive one character and 
store it in CHARACTER. If any errors described 
in the associated {error switch statement) occur 
while receiving, then the action defined in that 
(error switch statement) is taken. 

LINEDELETE.NULL causes the message text 
pointer to be set to the first character position if 
the linedelete character (as defined in the 
{terminal linedelete character statement) is 
received, and characters continue to be received 
and stored in the message text beginning at the 
first character position. 
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Statement 



Explanation 

CONTROL :NULL causes the (bit variable) 
CONTROLFLAG to be set TRUE if the control 
character of the station (defined in the (station 
control character statement)) is received, and 
characters continue to be received. 
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SHIFT STATEMENT 
Syntax 



SHIFT 



-UP 



-DOWN 



Semantics 

The (shift statement) is to be used in a (control definition) that communicates with stations using the 
Baudot (5-bit) character code set. (The character code set is defined in the (terminal code statement) 
of the associated (terminal definition) .) 

SHIFT UP indicates that received characters are to be translated to their respective uppercase graphics 
(usually referred to as FIGS). 

SHIFT DOWN indicates that received characters are to be translated to their respective lowercase graphics 
(usually referred to as LTRS). 

If the station does not use Baudot code, the (shift statement) acts as a no-op. 
Pragmatics 

In the Baudot character code set, most bit patterns have two graphic representations; one is referred to 
as FIGS (the uppercase graphic), and the other as LTRS (the lowercase graphic). 

When transmitting to a terminal that uses Baudot code, the terminal prints LTRS until it receives a ^ 
specially designated character indicating that it should shift to printing FIGS. The terminal continues 
printing the FIGS until it receives a specially designated character indicating that it should resume printing 
the LTRS. 

When information is received from a terminal that uses Baudot, the same conventions hold true; that is, 
the terminal communicates whether FIGS or LTRS follow, by the transmission of a designated character. 
The terminal initially transmits LTRS. 
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STORE STATEMENT 
Syntax 



STORE- 



- CHARACTER - 

•(string) 



SEQUENCE 



Jwtally- 

U-TOG — 



ENDOFBUFFER 



jy-a^ NULL r 

J \-**(label) ' 



-(tally number) ■•-] • 

'(toggle number) ^»] • 



Examples 



STORE. 

STORE CHARACTER [ENDOFBUFFER:20]. 

STORE "ABC" [NULL] . 

STORE SEQUENCE. 

STORE TALLY [0]. 

STORE TOG [0] , TOG [1 ] . TALLY [0] . 

Semantics 
STORE 

This form is semantically equivalent to the STORE CHARACTER construct. 
STORE CHARACTER 

This form causes the data contained in CHARACTER to be stored in the message space. If no message 

isTsSed with the (request definition) , then an implicit (getspaee statement) is executed 
SS *dl?SSSin tiie chapter position poiited to by the message text pointer, and the text pointer 
is updated after the STORE to point to the next forward character position. 

It is possible to encounter the end-of-the-text buffer when using this instruction. It is recommended that 
he optional syntax be included whenever using this statement. The optional syntax specifies action to be 
taken if the end of buffer is encountered. The NULL option specifies that the only action that should be 
Sen to set ENDOFBUFFER to TRUE. The (label) option specifies that the o«^^b^^^ 
tered contro should branch to (label) and also set ENDOFBUFFER TRUE. The ENDOraUFFER: part 
can be'ncluded for documentation. An implicit TERMINATE ERROR is executed if no end-of-buffer 
action is specified. 

STORE (string) 

This form causes (string) to be stored in the message space. If no message ^ » ^ ated 
with the (request definition) .an implicit (getspaee instruction) is executed. The (ftring) is stored 
fa the ^ mennpaefbeginning at the character position pointed to by the message text pointer and the 
texl uPSSSrThe STORE to point to the first character position following the (string) . 
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This instruction uses CHARACTER as a temporary storage area to store each character of (string). Thus, 
any data in CHARACTER prior to a STORE (string) instruction will be destroyed. 

It is possible to encounter the end-of-the-text buffer when using this instruction. Therefore, it is 
recommended that this instruction include the optional syntax. Refer to the STORE CHARACTER 
construct for the semantics of this syntax. 

STORE SEQUENCE 

Providing the station is in sequence mode (i.e., SEQUENCE is TRUE), the STORE SEQUENCE 
construct causes the current value of the sequence number to be stored in message word [5] .[26:27] 
is a binary integer, and message word [5] .[27.1 ] is set TRUE to indicate its presence. If the station 
is not in sequence mode (i.e., SEQUENCE is FALSE), then the instruction is a no-op. If no message space 
is present at the time of the STORE, then an implicit (getspace instruction) is executed first. 

STORE TALLY [ (tally number) ] 

This form causes the TALLY specified to be stored in the message space header. If no message space is 
present, an implicit (getspace statement) is executed just prior to the store operation. 

STORE TOG [ (toggle number) ] 

This form causes the TOGGLE specified to be stored in the message space header. If no message space 
is present, an implicit (getspace statement) is executed just prior to the store operation. 

Pragmatics 

The application of the STORE TALLY and STORE TOG constructs rests solely with the programmer. 
Since the message space is usually returned to a Message Control System (MCS), some mutual 
convention could be established between the NDL programmer and the MCS programmer as to the meaning 
of the contents of the TALLYs and TOGGLES. 
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Syntax 

SUM 

Al 



BCC 



CHARACTER- 



-*~RETRY- 
TALLY - 



'(tally number)- 



(single character) - 



Examples 



SUM Al. 

SUM CHARACTER. 

SUM "A". 

SUM TALLY [\\. 

Semantics 

The purpose of the (sum statement) is to affect the calculation of the horizontal parity check (whether 
that be a Block Check Character or a Cyclic Redundancy Check). The specific effect of the (sum state- 
ment) is dependent upon two factors: The SUMmed item, and whether the station's germinal 
definition) , for which (request definition) is running, defines horizontal parity as CRC(1 6) Following 
is a description of the effect that each form of the (sum statement) has on the calculation of the 
horizontal parity check. 

SUM 

Semantically equivalent to SUM CHARACTER. 
SUM Al. 

If the horizontal parity check is a Block Check Character or is undefined, the contents of Al are 
exclusively OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of Al and CRC, and the result is stored in CRC. 

SUM BCC 

If the horizontal parity check is a Block Check Character or is undefined, then the contents of BCC 
are exclusively OR-ed with itself, and the result is stored in BCC. (The result in BCC would be zero 
in this case.) 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of CRC[0] and CRC, and the result is stored in CRC. 
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SUM CHARACTER 

ir the horizontal parity check is a Block Check Character or is undefined, the contents of CHARACTER 
arc exclusively OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of CHARACTER and CRC, and the result is stored in CRC. 

SUM RETRY 

If the horizontal parity check is a Block Check Character or is undefined, the contents of RETRY are 
exclusively OR-ed with the contents of BCC, and the result stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of RETRY and CRC, and the result is stored in CRC. 

SUM TALLY [{tally number)] 

If the horizontal parity check is a Block Check Character or is undefined, the contents of TALLY 
[(tally number)] are exclusively OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the contents of TALLY [ (tally number) ] and CRC, and the result is stored in CRC. 

SUM (single diameter) 

If the horizontal parity check is a Block Check Character or is undefined, the (single character) is 
exclusively OR-ed with the contents of BCC, and the result is stored in BCC. 

If the horizontal parity check is a Cyclic Redundancy Check, the Cyclic Redundancy Check algorithm is 
computed with the (single character) and CRC, and the result is stored in CRC. 
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TERMINATE STATEMENT 
Syntax 

TERMINATE - 



BLOCK - 



■ENABLEINPUT- 



♦ ERROR- 



LOGICALACK 



♦ NOINPUT 



NORMAL 



(RETURN) 



Examples 

TERMINATE NORMAL. 
TERMINATE LOGICALACK. 
TERMINATE LOGICALACK( RETURN). 
TERMINATE. 

Semantics 

Each form of the (terminate statement) is described in the following paragraphs. 
TERMINATE 

This construct causes control to branch from a (request definition) and to begin executing the appropriate 
(control definition) . Any message that may be queued is left in the Station Queue (regardless of whether 
the message is incoming or outgoing) and STATION(QUEUED) is untouched. 

TERMINATE BLOCK 

In a Receive Request, this construct causes the following actions: 

a. an implicit (getspace instruction) is executed (in case the (request definition) may have been 
terminated without ever having acquired a message space); 

b. the Error Flag field, Last Flag Set field, and DCP RETRY are stored into the appropriate 
message fields; 

c. the "More-Blocks-to-Follow" bit (programmatically referenced by BLOCK) in the message 
(message word [0] . [29: 1 ] ) is set TRUE; 

d. the message is delinked from the Station Queue and linked into the DCP Result Queue; and 

e. control continues at the next sequential statement. 

In a Transmit Request, the TERMINATE BLOCK construct causes the following: 

a. the Error Flag field, Last Flag Set field, and DCP RETRY are stored into the appropriate 
message fields; 
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b. the message is linked into Ihc IXT Result Queue; ami 

c. the (request definition) is continued at the next sequential statement if STATION(QUEUED) 
is TRUE; otherwise, the (request definition) is suspended and put in a "sleep" state Until 
STATION( QUEUED) becomes TRUE. 

TERMINATE ENABLEINPUT 

This construct is allowed in Transmit Requests only. 
This instruction causes the following actions: 

a. the STATION(ENABLED) bit is tested; if STATION* ENABLED) is FALSE, then this instruc- 
tion acts as a no-op; otherwise, steps b through d are executed; 

b. the Error Flag field, Last Flag Set field, and DCP RETRY are stored into the appropriate 
message fields; 

c. the message is linked into the DCP Result Queue; and 

d. control leaves the Transmit Request and the station's Receive Request is entered. 
TERMINATE ERROR 

Tliis construct serves to inform the station's MCS of an unsuccessful attempt to complete a Receive or 
Transmit Request. This instruction inhibits the initiation of any new functions for the station. 

The result of the TERMINATE ERROR construct is as follows: 

"^W- a. STATION(READY) bit variable is set FALSE; 

b. a minimum-size message space is obtained, filled with error information for the MCS, and linked 
into the DCP Result Queue (its destination being the MCS); and 

c. the line is idle until the MCS takes some action. 

Additionally, if the TERMINATEing (request definition) was a Receive Request, any message space that 
may have been acquired to store a RECEIVEd message is discarded. 

The error message sent to the MCS contains the following information: 



MSG[0].[47:8] ,= 


99. 


[39:8] = 


AC Register contents. 


[31:8] = 


AI Register contents. 


[23:24] = 


Logical Station Number. 


MSG[1].[47:8] = 


Result Byte Index 


[39:6] = 


Line status prior to TERMINATE ERROR. 


[33:1] = 


LINE(TOG[l]). 


[32:1] = 


LINE(TOG[0] ). 


[31:8] = 


Last Flag Set in MSG[1 ] .[23:24] 


[23:24] = 


Error Flag field. 
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MSG|2|.|47:8| - CHARACTER. 

1 3<): I o | = I ast I XT "Sleep" address. 

MSGI4U 23:241 = Original DCWRITE TYPE. (Contains the original contents of MSGIO] .[47:24] 
prior to presentation of the message to the DCP.) 

Refer to appendix E. "The Error Result Message," in the B 6700/B 7700 DC ALGOL Reference Manual, 
form number 5000052, for more information regarding this message. 

TERMINATE LOGICALACK 

This construct is allowed in Receive Requests only. This instruction tests the LOGICALACK bit in the 
Station Table. (The semantics of the {station logicalack statement) describe how the LOGICALACK bit 
is set.) If LOGICALACK is FALSE, the instruction acts as a no-op and control continues at the next 
sequential statement. If LOGICALACK is TRUE, the following occurs: 

a. an implicit {geispace statement) is executed (in case the (request definition) is terminating 
without ever having acquired any message space); 

b. the ACKNOWLEDGE .READY bit in the Line Table is set (the consequences of this action are 
described subsequently); 

c. the "Message to be ACKNOWLEDGEd" bit is set in the Error Flag Field; 

d. the Error Hag Held, Last Hag Set Field, and DCP RETRY are stored into the appropriate 
message fields; 

e. the message is delinked from the Station Queue and linked into the DCP Result Queue; 

f the line is put in a "sleep" state until the station's MCS responds to the message with an 
ACKNOWLEDGE (TYPE = 44) DCWRITE; and 

g. upon receipt of the ACKNOWLEDGE, the Receive Request is allowed to continue at the 
next sequential statement. 

The ACKNOWLEDGEREADY bit is inaccessible to the NDL programmer, and it exists for each logical 
line in its Line Table. The only time that this bit will be TRUE is when a station's LOGICALACK bit is 
TRUE and its Receive Request has executed the TERMINATE LOGICALACK construct or the 
TERMINATE LOG IC ALACK( R ETU RN ) construct. Once TRUE, the ACKNOWLEDGEREADY bit will 
not be set FALSE, and the {request definition) will not be allowed to continue until the MCS executes 
the ACKNOWLEDGE (TYPE = 44) DCWRITE. 

TERMINATE LOGIC ALACK( RETURN) 

This construct is allowed in Receive Requests only. This instruction tests the LOGICALACK bit in the , 
Station Table. (The semantics of the (station logicalack statement) describe how this bit gets set.) If this 
bit is found TRUE, this statement functions exactly as does TERMINATE LOGICALACK; refer to that 
form for semantics. If LOGIC ALACK is FALSE, the following occurs: 

a. an implicit {ge (space statement) is executed (in case the (request definition) is terminating 
without ever having acquired a message space); 

b. the Error Flag field. Last Flag Set field, and DCP RETRY are stored into the appropriate message 
fields; 

c. the message is delinked from the Station Queue and linked into the DCP Result Queue; and 

d. control continues at the next sequential instruction in the (request definition). 
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TERMINATE NOINPUT 

If executed in a Transmit Request, this form is semantical^ equivalent to the TERMINATE construct (refer 
to that construct for semantics). When executed in a Receive Request, the following occurs; 

a. any message space that may have been acquired is discarded; 

b. LINE(BUSY) is set FALSE; and 

c. control branches to the appropriate (con trol definition). 
TERMINATE NORMAL 

The purpose of this construct is to signal the satisfactory completion of a (request definition) . If executed 
in a Receive Request, the following occurs: 

a. an implicit (getspace statement) is executed (in case the (request definition) is terminating 
without having ever acquired a message space); 

b. the Error Flag field, Last Flag Set field, and DCP ENTRY are stored into the appropriate 
message fields; 

c. the message space is delinked from the Station Queue and linked to the DCP Result Queue; 

d. LINE(BUSY) is set FALSE; and 

e control branches from the (request definition) and (providing the DCP does not take advantage 
of L1NE< BUSY) set FALSE to initiate a (request definition) ) the appropriate ((-on trot 
definition) is entered. 
If TERMINATE NORMAL is executed in a Transmit Request, the following occurs: 

a. the Error Flag field, Last Flag Set field, and DCP RETRY are stored into the appropriate message 
fields; 

b. the message is linked into the DCP Result Queue; 

c. LINE(BUSY) is set FALSE; and 

d control branches from the (request definition) and (providing the DCP does not take advantage 
of LINE BUSY) set FALSE to initiate a (request definition) the appropriate (control definition) 
is entered. 

In the Transmit Request case, the message linked to the DCP Result Queue isji res ult '"^('j^*"?' 
a GOOD RESULTS (CLASS = 5) Message). The intended destination is the MCS; however, the MCS has 
the option of whether to accept GOOD RESULTS Messages or to have the DCC discard them. 
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TRANSMIT STATEMENT 
Svntax 



TRANSMIT 



-•►ADDRESS 



hs-BCC 



C RECEIVE 
TRANSMIT 



T 

fT-J 



3 



-•►CHARACTER 
-*~CRC 



-^SEQUENCE 

TEXT 

-TRAN 



-(string)- 



L^[-^BREAK 



-(label)- 
^NULL-*J 



**1 J 



Examples 



TRANSMIT. 

TRANSMIT CHARACTER [BREAK:NULL] . 
TRANSMIT SOH STX 4"00" [BREAK: 10] . 
TRANSMIT TRAN. 

TRANSMIT ADDRESS(TRANSMIT)[BREAK] . 
TRANSMIT TEXTIBREAK] . 
TRANSMIT "LITERAL STRING". 



Semantics 



The (transmit statement) causes the adapter cluster to transmit information to a terminal. The following 
group of syntax options specifies the information to be transmitted. All options, except CHARACTER, use 
the (byte variable) CHARACTER as a temporary storage area; thus, any information contained in 
CHARACTER before execution of the (transmit statement) shall be destroyed by the (transmit statement). 
If none of the first group of options are chosen, it is semantically equivalent to specifying CHARACTER 
(i.e., TRANSMIT is equivalent to TRANSMIT CHARACTER). 

ADDRESS 

The proper number of characters (as specified by the station's (terminal definition) in the (terminal 
address size statement)) are taken from the Address field in the Station Table and transmitted. 

ADDRESS( RECEIVE) 

This option is equivalent to ADDRESS, except that ADDRESS(RECEIVE) must be used when an address 
pair is defined in the (station address statement) and the programmer wants to transmit the receive address. 
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ADDRESS(TRANSMIT) 

Tins option is equivalent to ADDRESS, except that ADDRESSER AN SMIT) must be used when an 
lldrcss^irrdcfined in the (station address statement) and the programmer wants the transmit address 
transmitted. 

BCC 

The BCC option causes the content of the (byte variable) BCC to be transmitted. 
CHARACTER 

The CHARACTER option causes the content of the (byte variable) CHARACTER to be transmitted. 
CRC 

This option causes two bytes to be transmitted; CRQ01 is transmitted first, followed by CRC[1 1 ... If the . 
2iion^^c/^>to»> does not define horizontal parity as CRC(16), the use of this option causes 
a syntax error to be generated at compile time. 

SEQUENCE 

This option causes the character representation of the value stored in the ^^^^hTWJEY 
Table to be transmitted if the station is in sequence mode (i.e., the (bit variable) SEQUENCE is TRUE), 
otherwise, the (transmit statement) is a no-op. 

TEXT 

This option extracts characters, one at a time, from the associated message, using 5 CHARACTER as a . 
I»a™ storage area, and transmits the characters until the end of the text buffer is encountered. At that 
2t control branches to the next statement. The TRANSMIT TEXT construct is, in effect, the same as 
the following loop: 

I: FETCH IEND0FBUFFER:21 . 
TRANSMIT CHARACTER. 
GOTOl. 



This option can only be used with the (transmit statement) in Transmit Requests. 
TRAN 

The proper number of transmission number characters (as defined by the station's (terminal definition) 
^tir^ZrZnsmission number length statement)) ** extracted from the Transmit Transmission 
Number field in the Station Table and then transmitted. 

(string) 

Each character of (string) , using CHARACTER as a temporary storage area, is transmitted. 
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The BREAK option allows the programmer to specify action if a "break' 5 is received from the terminal 
while the adapter cluster is still transmitting. If this option is omitted and a break occurs, an implicit 
TERMINATE ERROR instruction is executed. The following describes the actions of the three syntactical 

forms: 

BREAK sets TRUE the (bit variable) BREAK I TRANSMIT J and causes a branch of 

control to the next statement. 

BREAK: (label) sets TRUE the (hit variable) BREAK [TRANSMIT] and causes a branch of 

control to (label) . 

BREAK:NULL causes no action. Execution proceeds as if the break did not occur. 
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WAIT STATEMENT 
Syntax 

WAIT 

Examples 



• (wait time}- 



-(label)- 



WAIT. 

WAIT (3 SEC). 
WAIT(5MILLI:6). 

Semantics 

The (wait statement) is only allowed in (request definitions that are written to communicate with full 
Zle^rmUwl type! Execution of this statement causes the (request definition) to be suspended un u 
the ^c^lhie executes a (continue statement). The optional syntax effects the statement as desenbed below. 

(wait time) defines the maximum amount of (time) that the (request definition) should 

N be suspending waiting for the (continue statement) . If (wait time) is 

exceeded and the co-line has not executed a (continue statement) . execution 

resumes at the next sequential statement. 

(wait time\ : (label) same as above except execution resumes at (label) if a (c ontinue 
x ' statement) is not executed witlun (wait time) . 

Pragmatics 

Refer to the (fork statement) pragmatics. 
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STATION DEFINITION 
Syntax 



STATION 



. (station identifier ) - 



DEFAULT -^(default station identifier) 



?er>J 



'(station adapter statement) — 

-(station address statement) 

.(station control character statement)- 
.(station default statement) 



.(station enableinput statement) — 
.(station frequency statement)—— 

'(station initialize statement) 

.(station logicalack statement) — — 

.(station MCS statement) 

■» (station modem statement) 

► (station myuse statement) 1 — 

•.(station page statement) 

m(siution phone statement ) — — — 
* (station retry statement) • — — — 
*. (station terminal type statement ) 
» (station width statement ) ■ 



Examples 

STATION KMET: 

ENABLEINPUT 
MCS 

CONTROL 

RETRY 

LOGICALACK 

MYUSE 

TERMINAL 



FALSE. 

SYSTEM/CANDE. 

4"6F". 

15. 

FALSE. 

INPUT, OUTPUT. 
TELETYPE. 



STATION DEFAULT STADFLT2: 



CONTROL 
MCS 

ADAPTER 
DEFAULT 



= 449" 

= SYSTEM/CANDE. 
= 4. 

= STADFLT1 
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Semantics 

(station identifier) and (default station identifier) have the syntactical form of a (system identifier), 
llach syntactical form of the (station (y(./)//;7/V>rt) is described subsequently. 

STATION (station identifier) : . . . 

This form of the (station definition) defines the attributes of a station. The attributes must be defined in 
one of the following ways: 

a. Hach attribute is explicitly defined by means of a (station statement). 

b. fcaeh attribute is defined implicitly by means of an explicit reference to a set of previously 
defined default attribute values. 

c. Some of the attributes are defined implicitly as in b, and the remainder are defined explicitly as 
in a. 

Some of the station attributes must be defined for each station; others do not. Some of the statements 
may or may not be required, depending upon the appearance of other statements. The semantics portion 
of each (station statement) states, among other tilings, whether the attribute must be defined and its 
effect upon the requirements of other (station statements. 

To define the attributes of a station as described in item a above, only this syntax form is used. 

To define the attributes of a station as described in items b and c above, this syntax form, the following 
syntax form, and the (station default statement) must be used in conjunction (this is described under the 
following syntax form). 

STATION Dl-FAULT (default station identifier) : . . . 

This form is referred to as a Default (station identifier). Its purpose is to decrease the number of source 
statements required to define all of the stations. This is accomplished in the following manner. Attributes 
common to several stations are defined by means of a Default (station definition) . Associated with each 
Default (station definition) is a (default station identifier) . Subsequent to the Default (station 
definition), any (station definition) can reference the (default station identifier) , instead of repeating 
the list, a' (default station identifier) is referenced by means of a (station default statement). The NDL 
compiler uses the last definition of a station attribute, and therefore the programmer can reference a 
Default (station definition) and change any attributes by redefining them in the (station definition) . 

In appearance, the Default (station definition) is similar to the (station definition). The differences are 
that the reserved word DEFAULT follows the reserved word STATION, and that there are no statements 
that are required to appear in a Default (station definition). 
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STATION ADAPTER STATEMENT 

Svntax 



ADAPTER ► = — I — — ^(communication type number) — - ; V 

[^(^(communication type number)^ ^(communication type number)**)^ 



Examples 



ADAPTER - 4, 
ADAPTER s (11,6). 



Semantics 



The (startm Planter statement) defines a combination of character format, 

communieation and line speed (in the case of synchronous communications) that the DCP must use to 
co mm c Ite^th the terminal associated with the station. This is done by supplying ^(communication 
plumber) (or number pair). Table 5-4 lists the allowed (communication type numbers and the 
characteristics associated with each. 

For example, 

ADAPTER = 4. 

This statement defines an 11 -bit character format, asynchronous communication, at a line speed of 1 10 bits 

per second. 

If the station's associated terminal type utilizes full duplex (i.e., the (terminal duplex statement) specifies 
DUPLFX=TRUE), and the primary and the auxiliary lines have different characteristics, then a 
(communication type number) pair must be supplied. 

For example, 

ADAPTER = (1 1,6). 

This statement defines for the primary line a 10-bit character format, asynchronous communication, at a 
s,S of 1 800 bits per second. The characteristics associated with the auxiliary line are the same except 
that it runs at a line speed of 1 50 bits per second. 

The statement: 

ADAPTER = (6,6). 
is semantically equivalent to: 

ADAPTER = 6. 

The /communication type number) (or number pair) defined in this statement must be one of those _ 

KstedSn the (terminal adapter statement) of the station's associated (terminal definition) . The (station 

adapter statement) is required unless the (terminal adapter statement) lists only one (communication type 

number) (or number pair), in which case, the (station adapter statement) may be omitted and the 

(terminal adapter statement) specification is used. ^ 
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Supplementary Examples 

The following program fragments illustrate valid adapter statement specifications. 

Example 1 

MODEM AMODEM: 

ADAPTERS ,2,3,4,5,6,7,8,9,10. 



TERMINAL ATERMINAL: 

ADAPTER=6,7,8,9,11 ,12,1 3,14,1 5. 



STATION ASTATION: 

ADAPTER=7. 
MODEM=AMODEM. 
TERMINAL= ATERMINAL. 



Example 2 

MODEM DUPLEXMODEM: 

ADAPTERS, (1 1,6), (12,6), 12. 



TERMINAL DUPLEXTERMINAL: 
ADAPTER=6,<11,6). 



STATION DU PLEXSTATION : 

ADAPTERS 11, 6). 

MODEM=DUPLEXMODEM. 

TERMINAL=DUPLEXTERMINAL. 
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STATION ADDRESS STATEMENT 
Syntax 



ADDRESS 



Examples 



(string) — 

( ■ * (string)* 



>(string)~ 



ADDRESS 
ADDRESS 
ADDRESS 



4"01'\ 

(4 6 H>oor\4"oi"). 

"A". 



Semantics 



The (station address statement) defines the actual address characters of the station's terminal that are 
required for operations such as polling and selecting. The number of characters in the (string) (s) must be 
equal to the number defined in the (terminal address size statement) of the associated terminal. This 
statement is not allowed in Default (station definitions). 

ADDRESS * (firing). 

This form of the statement is used when the receive address and the transmit address are the same. 
ADDRESS = ( (string) , (string) ). 

This form of the statement must be used if the receive address and the transmit address differ. The first 
(string) defines the receive address characters, and the second (string defines the transmit address 
characters. 

Pragmatics 

The address characters of a station can be changed as a result of the Message Control System (MCS) 
executing a SET CHARACTERS (TYPE - 39) DCWRITE. 
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STATION CONTROL CHARACTER STATEMENT 
Syntax 



CONTROL ► = — (single character) — — — • 

Example 

CONTROL = "?". 
Semantics 

The (station control character statement) defines the control character of the station. The control 
character can be recognized by the DCP when RECEIVEd in a message text from the station, and any 
action to be taken can be specified by the programmer using the CONTROL syntax in the (receive 
statement). 
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STATION DEFAULT STATEMENT 
Syntax 

DEFAULT = — — ^(default station identifier)-^ — — — — *- • 



The (station default statement) allows the programmer to specify the (default station identifier) of a set 
of previously defined default station attributes to be used for a (station definition) whose description is 
incomplete. It is advantageous to group common attributes under a Default (station definition} and list 
the remaining attributes under each individual (station definition) . The compiler will then refer to the 
Default (station definition) to complete the (station definition) •. The (station default statement) is not 
required to appear in each (station definition) ; however, a (station definition) must define all required 
attributes locally if a ( tation default statement) does not appear. 



Supplementary Example 

The following is an example of how a Default (station definition) can be used in conjunction with a 
(station definition). 



Example 



DEFAULT = STADFLT 1. 



Semantics 



The (station default statement) can appear in a (station definition) or a Default (station definition). 



STATION DEFAULT STADFLT: 



MCS 

CONTROL 

RETRY 

LOGICALACK 

MYUSE 

TERMINAL 

ENABLEINPUT 



15. 

FALSE. 

INPUT, OUTPUT. 

TELETYPE. 

TRUE. 



SYSTEM/CANDE. 




| Default (station definition)} 



STATION TESTSTATION: 



(station default statement) references 
Default (station definition) above to 
complete the (station definition) . 



DEFAULT 

MODEM 

MCS 



STADFLT. — 

MABELL103A. 

SYSTEM/DIAGNOTICMCS. 

4. 



ADAPTER 
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STATION EN ABLEINPUT STATEMENT 
Syntax 



ENABLEINPUT 



-TRUE ■ 
FALSE 



Semantics 

The (station enableinput statement) defines the initial state of the station's "enabled" bit (proeram- 
matically referred to as ST ATION( EN AB LED )). This statement must be defined in each (station 
definition). ; N . 

ENABLEINPUT - TRUE. 

This construct causes the "enabled" bit to be initially TRUE after DCP initialization, and the station is 
said to be enabled for input," or simply "enabled." 

ENABLEINPUT = FALSE. 

i 

This construct causes the "enabled" bit to be initially FALSE after DCP initialization, and the station is 
said to be "disabled for input," or "disabled." 

Pragmatics 

Whether a station is enabled or disabled for input can directly affect the execution sequence of instructions 
in the (control definition) and (request definition) (5) designated for that station. Specifically, if the 
station is disabled for -input ■-control will never branch to the Receive Request for that station as a result 
£™?!£ n JSy£2£ ENABLEINPUT or a TERMINATE ENABLEINPUT construct. Refer to the 
INITIATE ENABLEINPUT and TERMINATE ENABLEINPUT constructs for more detailed information. 

!*A*fS2rS5iS^ "enabled" bit, after DCP initialization, by means of the 

ENABLE INPUT (TYPE * 35) DCWRITE or the DISABLE INPUT (TYPE = 36) DCWRITE. 
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STATION FREQUENCY STATEMENT 
Syntax 

FREQUENCY ^(integer) 



Example 

FREQUENCY = 10. 
Semantics 

The (station frequency statement) defines the initial value of the (byte variable) programmatically 
referred to as STATION (FREQUENCY). The (c ontrol definition) specified for the station can reference 
the (byte variable) and use the value stored there in any way that the programmer sees fit; however, the 
intended use of the variable is to influence in some way the rate at which a polled station is polled. In the 
polling (control definition) provided by Burroughs Corporation in SYMBOL/SOURCENDL, 
FREQUENCY specifies a relative polling rate: means poll at the highest rate, 1 means to poll at a slower 
rate, 2 means to poll at a still lower rate, etc. 

The (integer) must not exceed a value of 255. 

The MCS of the defined station can change the value of STATION( FREQUENCY) by means of an ENABLE 
INPUT (TYPE = 35) DCWRITE. 
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STATION INITIALIZE STATEMENT 
Syntax 



INITIALIZE 



■•►TOG — j+- 
**TOGS-» 



[—m»(toggle number) — *►] 



-+> TALLY -»* [ -*(tally number)-*- ] [ -+>(bit number)-*-) ■ 
♦TOGS 



= -p»-TRUE- 
U-FALSE 



If 



♦■TALLY -* [ -*(tally number)-*] 



= -y^(integer) 



\-».(single character)- 



Examples 



INITIALIZE TOGS = 4"FF'\ 
INITIALIZE TOG|0| = TRUE, 
TALLY 1 1 1 =25, 
TALLY |0| |7| = TRUE. 
INITIALIZE TALLY|0| = "?". 



Semantics 



The /station initialize statement) provides the means to define initial values for the station TOGGLEs and 
TALLY s. Any initial values defined for station TOGGLEs and TALLYs are stored in the TOGGLEs and 
TALLYs at DCP initialization time only. 
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STATION LOCK -ALACK STATEMENT 
Syntax 



LOGICALACK 



►TRUE— 
-FALSE 



Semantics 

The (station logicalack statement) defines the initial state of a bit, referred to as the Logicalack bit in the 
Station Table. TRUE or FALSE can be specified, indicating the initial state as on or off respectively If the 
LOGICALACK bit is on, special action is taken if the Receive Request executes either the TERMINATE 
LOGICALACK or TERMINATE LOGICALACK( RETURN) constructs of the (terminate statement). 
This statement is required in (station definition)s. 

The MCS of the station can change the value of the Logicalack bit after DCP initialization by means of the 
SET/RESET LOGICALACK (TYPE = 43) DCWRITE. 
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STATION 

Station MCS Statement 

STATION MCS STATEMENT 
Syntax 

MCS *»(MCS identifier) — • 

Examples 

MCS = SYSTEM /R J E. 
MCS = SYSTEM/APL. 
MCS = UTILITY/MCS. 

Semantics 

The (station MCS statement) defines the Message Control System (MCS) that is responsible for handling 
messages to and from the station. If the MCS named is not an MCS defined in a (MCS definition) , it is 
added to the list of valid MCS programs to be contained in the Network Information File, and the MCS will 
not be allowed to execute diagnostic DCWRITEs. Refer to the semantics of the (MCS definition) for 
information regarding the diagnostic DCWRITEs. This statement is required in (station definitions. 
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STATION 
Station Modem Statement 



STATION MODEM STATEMENT 
Syntax 



MODEM 



-(modem identifier)- 



Example 

MODEM = BELL20I. 
Semantics 

The (station modem statement) applies to a station thai has associated with it a terminal type that must 
communicate with the Data Communications System through the use of a modem. This statement 
associates the modem type (i.e., a (modem definition) ) used for that purpose with the station. It this 
statement is omitted from the (station definition) , and the (line definition) lor the line to which the 
station is assigned (if, in fact, the station is assigned to a line) does not contain a <////(- modem statement) , 
then the compiler assumes a direct connection between the terminal and the line adapter. 

The 'modem identifier) must name a (niodein definition) that is compatible with the defined station 
attributes To be more specific, the (communication type number) specified in the (station adapter 
statement) (or in the (terminal adapter statement) of the station's (terminal definition) if no (station 
adapter statement") appears) must be one of the (communication type number) s listed in the (modem 
adapter statement) of the modem named. 

After DCP initialization, the MCS of the station may change the (modem definition) associated with the W„ 
station, by means of the MOV Y.I ADD/SUBTRACT STATION (TYPE = 130) DCWRITE. 
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STATION 

Station My use Statement 



STATION MYUSE STATEMENT 
Syntax 

MYUSE = -i INPUT 



OUTPUT 
INPUT— 



OUTPUT 



OUTPUT- 
INPUT — 



Semantics 

The Ration myuse statement) defines to what extent an object job can use the station as in input 
or output device. 

MYUSE=INPUT specifies that an object job can use the station as an input file only. 
MYUSE=OUTPUT specifies tliat an object can use the station as an output file only. 
MYUSE=INPUT,OUTPUT or MYUSE=OUTPUT,INPUT specifies that an object job can use the station as 
an input and/or output file. 

A (terminal request statement) must be defined by the station's (terminal dejinitiori) for handling input 
and/or output capabilities as specified in the (station myuse statement) . Thus, if the station is to send 
input to, and receive output from, an object job, the station's (terminal definition) must specify a Transmit 
Request and a Receive Request. 

Note that the (station mvuse statement) restricts the use of the station by object jobs only The MCS 
can communicate with the station to the extent specified in the (terminal request statement) ot the 
station's qerminal definition) . That is, regardless of what is specified in the (station myuse sta ement) , 
the MCS can receive information from, or send information to, a station, provided that the station s 
(terminal definition) specified a Receive and Transmit Request. 

The station MYUSE attribute can be interrogated by an object job through reference to the MYUSE 

file ^attribute ^ For further information, refer to the B 6700 Input/Output Subsystem Informat.on Manual, 

form number 5000185. 
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Station Page Statement 

STATION PAGE STATEMENT 
Syntax 



PAGE — - = ^(integer) 



Examples 



PAGE = 12. 
PAGE = 0. 



Semantics 

specifications for pagination are used. 

form number 5000185, for more information. 
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STATION 

Station Phone Statement 



STATION PHONE STATEMENT 
Syntax 

PHONE '-+> = —^(integer) , — — 

Example 

PHONE = 12136572385. 
Semantics 

The (station phone statement) is implemented for documentation purposes only. This statement 
documents the telephone number that the system would have to dial to reach the station's terminal, 
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STATION 
Station Retry Statement 

STATION RETRY STATEMENT 
Syntax 



RETRY 



(integer) 



Example 



RETRY = 3. 



Semantics 

The (station retry statement) defines a 
(hvte variable) for more information. 



default value for DCP INITIAL RETRY. Refer to the RETRY 
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■•. \ ■ / station 

Station Terminal Type Statement 

STATION TERMINAL TYPE STATEMENT 
Syntax ; '. ' '■' 

TERMINAL = —^(terminal identifier) r — ■ 

Examples 

TERMINAL = APLTERM. 
TERMINAL = TTY. 

Semantics 

The (station terminal type statement) associates a terminal type with the station. This statement is 
required in a (station definition) . 

After DCP initialization, the MCS of the station can change the terminal type associated with the station 
by means of the MOVE/ADD/SUBTRACT STATION (TYPE = 130) DCWRTTE. 



9. *.'" 
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i, .* -STATION ? - 

Station Width Statement 

STATION WIDTH STATEMENT W 

Syntax 

WIDTH = — — s** < integer) » > - t » • 

Examples 

WIDTH = 72. 
WIDTH = 132. 

Semantics 

The (station width statement) defines the number of characters in a logical display line of output on the 
station's terminal. If this statement is not included in a (station definition) , then the WIDTH defined 
for the station's (terminal definition) is the default station WIDTH. 

An object job can interrogate a station's WIDTH by testing the value of the WIDTH file attribute. Refer 
to the B 6700 input/Output Subsystem Information Manual , form number 5000185, for further 

information. 



^^^^^ 
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TERMINAL 



TERMINAL DEFINITION 
Syntax 

TERMINAL-!-"*- (terminal identifier) 



'-♦DEFAULT-** (default terminal identifier) 



en ti tier)-* 



^(terminal backspace cliaracter statement). 
•^(terminal carriage character statement) — 
^.(terminal clear character statement)- — — — 

•(terminal code character statement)—* 

^.(terminal control statement) ■ 

^(terminal default statement) 

-»» (terminal duplex statement) ■■■ ■ ■ 



(terminal adapter statement)—— 
-(terminal address size statement)^ 
m(terminai buffer size statement)— 



-^(terminal end character statement)— 
-(terminal home character statement)- 
^(terminal illegal character statement)- 
-^(terminal inhibitsync statement) — — 



-^(terminal inter-character delay statement)- 
-^(terminal linedelete character statement)— 
•.(terminal linefeed character statement) — 
•^(terminal maxinput statement) . < 

* (terminal page s tate nient) — — 

» (terminal parity state tnent) > ■ 

-»» (terminal request statement)* ■ 

(terminal screen statement). ■ 



+ (terminal timeout statement)' 



-^(terminal transmission number length statement)-** 

-^(terminal turnaround statement) 

•.(terminal width statement) 



-*±(terminal wru character statement)* 
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TERMINAL . 
Continued > ] 

Examples 

TERMINAL TTY: 

CODE = ASC67. 

PARITY ■ NULL. 

SCREEN = FALSE. 

BUFFER ■ NULL. 

DUPLEX ■ FALSE. 

ADDRESS ■ NULL. 

WIDTH = 72. 

MAX1NPUT = 72. 

TIMEOUT « 300 SEC. 

REQUEST = RECEIVE: READTTY, 

TRANSMIT: WRITETTY. 

CONTROL = CONTENTIONDEVICE. 

TERMINAL DEFAULT DEFAULTLIST1 : 

CODE - ASC67. 

PARITY = NULL. 
SCREEN = FALSE. 
BUFFER = NULL. 

Semantics 

(terminal identifier) and (default terminal identifier) each have the syntactic form of (identifier) . 
Eacli construct of the (terminal definition) is described subsequently. 
TERMINAL (terminal identifier) : ... 

This form of the (terminal definition) syntax defines the attributes of a terminal type in the data 
communications network. Most terminal attributes are hardware-dependent. The attributes of the 
terminal type are defined in one of the following ways: 

a. Each attribute is defined explicitly by means of a (terminal attribute statement) in the 
(terminal definition) . 

b. Each attribute is defined implicitly by an explicit reference to a set of previously defined 
default attribute values. 

c. Some of the attributes are defined implicitly as in b, and the remainder are defined explicitly 
as in a. 

Some of the (terminal statements must be defined for each (terminal definition) ; others do not. 
Some of the statements may or may not be required, depending upon the appearance of other state- 
ments. The semantics portion of each (terminal attribute statement) states, among other things, 
whether the attribute must be defined and its effect upon the requirement of other attribute definitions. 

To define the attributes of a TERMINAL as described in item a above, this syntax form must be used. 

To define the attributes of a terminal type as described in items b and c above, this syntax form, the 
following syntax form, and the (terminal default statement) must be used in conjunction (this is described 
under the following syntax form). ^ 
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TERMINAL DEFAULT {default terminal identifier) : . . . 
This form is referred to as a Default (terminal definition) . 

Its purpose is to decrease the number of source statements required to define all of the terminal types in 
the data communications system. This is accomplished in the following manner. Attributes common to 
several terminal types are defined by means of a Default (terminal definition) . Associated with each 
Default (terminal definitioti) is a (default terminal identifier) . Subsequent to the Default (terminal 
definition) , any (terminal definition) that has those attributes in common may reference the default 
terminal identifier) , instead of repeating the list. (A (default terminal identifier) is referenced by means 
of a (terminal default statement) .) The NDL compiler uses the last definition of a terminal attribute, and 
therefore the programmer can reference a Default (terminal definition) and change any attributes by 
redefining them in the (terminal definition) . 

In appearance, the Default (terminal definition) is similar to the (terminal definition) . The differences 
are that the reserved word DEFAULT follows the reserved word TERMINAL, and that no statements are 
required to appear in a Default (terminal definition). 

Supplementary Example 

Below is an example of how a Default (terminal definition) can be used in conjunction with a 
(terminal definitioti) . 

/ DEFAULTLIST1 is the < default 
\ terminal identifier) of this Default 
I (terminal definition) . The set of default 
] attributes that follows is referenced by 
\ this name. 

(terminal statement) s define the default 
attributes associated with DEFAULTLIST1 



TERMINAL DEFAULT DEFAULTLIST1 : 



CODE = ASC67 
PARITY = NULL 
SCREEN = FALSE 
BUFFER = NULL 



E 1 



{ 



Above DEFAULTLIST1 has associated with it four attributes. Any subsequent (terminal definition) 
in a source program can reference these default attributes by the appearance of a (terminal default 
statement) in the (terminal definition) . The (terminal default statement) has the form: 



DEFAULT - 



• (default terminal identifier)- 



where the (default terminal identifier) must name a previously defined Default (terminal definition) . 
More information regarding the use of Default (terminal definition) s in conjunction with (terminal 
default statement)* can be found in the (terminal default statement) semantics. 

Below, TTY uses the (terminal default statement) to reference DEFAULTLIST1 . DEFAULTLIST1 
contains the attribute information required to complete the (terminal definition) TTY. 



TERMINAL TTY: 

DEFAULT 

DUPLEX 

ADDRESS 

WIDTH 

MAXINPUT 

TIMEOUT 

CONTROL 

REQUEST 



SThis ( terminal default statement) 
references the Default ( terminal 
definition) defined previously. 



DEFAULTLIST1 

FALSE. 
NULL. 
72. 
72. 

300 SEC. 

CONTENTIONDEVICE. 

RECEIVE: READTTY, TRANSMIT: WRITETTY. 
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Terminal Adapter Statement 

TERMINAL ADAPTER STATEMENT 
Syntax 



ADAPTER— = ^{communication type number ) — T 

^^(communication type number)-** * ^{communication type number 



.(communication type number) 

Examples 

ADAPTER = 4. 
ADAPTER = (6,10), (10,6). 
ADAPTER = 5, (5,6), 6. 

Semantics 



Tho /terminal adavter statement) defines one or more combinations of character format, synchronous/ 
I^nfiS'^uSSSSnd line speed (m the case of asynchronous ^— !^^2^ 
the terminal type is compatiole. This is done by supplying one or more <^J^^"^^^ ?S 
(or number pairs). Table 5-4 lists the allowed (communication type number) sand the characteristics 

associated with each. 

numbers listed for the connecting modem in the (modem adapter statement) . 
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Terminal Address Size Statement 



TERMINAL ADDRESS SIZE STATEMENT 
Syntax 

ADDRESS — ^ -*-NULL- 



!-*».( receive address size ) 



L, -^(transmit address size) ^ L (DIFFERENT) ^ 



Examples 



ADDRESS = 2. 

ADDRESS = 2 (DIFFERENT). 
ADDRESS = 3,2 (DIFFERENT). 
ADDRESS = 2,3. 



Semantics 



The (terminal address size statement) defines the number of address characters tha the terminal type 
transmitTaXeceives. The number of address characters must not be confused with the actual address: 
SSSs "sed in polling and selecting; the (station address statement) defines the actual address char- 
acters This attribute must be defined when actual address characters are defined in the {station 
address statement) of a (station definition) that references the (terminal definition). 

( receive address size) and (transmit address size) must be integers greater than zero and less than 4. ^ 
The (receive address size) defines the number of address characters the terminal expects to receive and 
the (Iransmit address size) defines the number of address characters that the terminal ransmits It he 
(transmit address size) is not defined, it is assumed the (transmit address size) is equal in length to the 
fece ™ address sizeY. The (receive address size) and the (transmit address size) for a given terminal 
S concur with the lengthbf the character (string) (s) defined as the actual address characters in the 
(station address statement) of any (station definition) which references the (terminal definition) , 
otherwise, a syntax error results. 

The (DIFFERENT) option must be used if the (receive address) and the (transmit address) , as defined 
in the (station address statement) , are not identical. 



Definitions 
TERMINAL 
Terminal Backspace Character Statement 



n — n 

1 — (DYNAMIC) 1 



TERMINAL BACKSPACE CHARACTER STATEMENT 
Syntax 

BACKSPACE *- = single character) ■ 

(DYNAMIC) 

Examples * . 

BACKSPACE = 4"! 6". 
BACKSPACE (DYNAMIC). 

• - 

Semantics 

The (terminal backspace character statement) defines the backspace character of the terminal type 
(i.e., the character that the terminal type would transmit to indicate that the previous ^character should 
be deleted). If defined, the backspace character can be recognized by the DCP when RECEIVEd (ura 
< receive statement) ), and any action to be taken can be specified by the programmer (using the 
BACKSPACE syntax). 

(DYNAMIC) indicates that the controlling MCS of a station referencing ^^^ir^t^v-^ 
allowed to change the backspace character for the station by means of a SET CHARACTERS (I Yrfc-oy) 
DCWRITE. 
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Terminal Buffer Size Statement 



TERMINAL BUFFER SIZE STATEMENT 
Syntax 



BUFFER -*- = 



Examples 



NULL- t- 

■ ( integer ) • 



BUFFER = NULL. 
BUFFER = 960. 



Semantics 



The (terminal buffer size statement) applies to buffered devices and defines thesize, in characters, 
of the terminal type buffer. If the terminal type is an unbuffered device, the form. 

BUFFER = NULL. 

can be used, or the statement may be omitted- additionally if the device is unbuffered, the (terminal 
maxinput statement) must be defined for the (terminal definition) . 
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TERMINAL 
Terminal Carriage Character Statement 



TERMINAL CARRIAGE CHARACTER STATEMENT 
Syntax 

CARRIAGE — ► - ► (single character) ; * 

Example 

CARRIAGE = 4"0D". 
Semantics 

This statement is implemented for program documentation purposes only. This statement provides a 
means of documenting the carriage return character of a terminal type. The documentation of this 
character is optional in a (terminal definition) . 
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Terminal Clear Character Statement 



TERMINAL CLEAR CHARACTER STATEMENT 
Syntax 

CLEAR *** = ( single character ) — — * 

Example 

CLEAR = 4"1 V\ 
Semantics 

This statement is implemented for program documentation purposes only. It provides a means to 
document the clear character of a terminal type. The documentation of this character is optional in a 
(terminal definition). 
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Terminal Code Statement 



TERMINAL CODE STATEMENT 
Syntax 

— ► ASCII (BINARY) 

— »»• ASC67 

». ASC68 — 



CODE »■ 



BAUDOT 



BCD 
BCL 



-o* BINARY 



EBCDIC 



PTTC6I 



Semantics 

The {terminal code statement) specifies Ihe character code transition required ro ^^ D CP^o 
communicate will, the terminal type. The internal code ol the D P is EBC DIC amT tl ^P *ra si.tes 
from KBCD1C to the code specified for transmissions, and from the code sped .ed to EBCDIC for 
receptions. 

BINARY and EBCDIC specify that translation is not required. 

ASC67 and ASC68 specify the standard software translation tables for the ASCII character code. 

ASCII (BINARY) allows a (control definition) or {request definition) to switch back and forth between 
ASC code trans ation and no translation. The (code statement) in a (request definition) or 

>X s the switch back and forth. The application of this feature is to allow a 
truest WnMon] Control definition) to enter a "transparent" mode in Bmary Synchronous 
communications procedures. 

BAUDOT, BCD, BCL, and PTTC6I specifications are all indicative . of the translation they invoke. For 
example. BAUDOT invokes the Baudot character code set, PTTC6I invokes PTTC/6, etc. 

Pragmatics 

For special applications a programmer can define and invoke non-standard character codes by: 

a. defining a translation table in a (translatetable definition) ; 

b. specifying BINARY or EBCDIC in the (terminal code statement) ; and 

c. invoking the translation in a (control definition) ox (request definition) by means of the 
appropriate option of the (assignment statement) . 

Refer to the (translatetable definition) in this chapter for more information. 
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Terminal Control Statement 



TERMINAL CONTROL STATEMENT 
Syntax 

CONTROL — ^ = (control identifier)- 



L^. , — (control identifier) ^ 



Examples 



CONTROL = CONTENTION. 
CONTROL = PRIM ARYCONTROL, 

AUXILIARYCONTROL. 



Semantics 



The (terminal control statement) specifics the (ivntrol dcfinition)(s) responsible for allocation of the 
logical line(s) to which a terminal type is associated. This attribute must be defined for all (terminal 
definitions). 

Terminal types that do not utilize full duplex, reverse channel, or voice response features require that only 
one (control identifier) be named. 

Terminal types that utilize full duplex, reverse channel, or voice response features (i.e., DUPLEX = TRUE) 
may optionally specify a second (control identifier). The first (control identifier) names the (control 
definition) for the primary line, and the second (control identifier) names the (control definition) for 
the auxiliary line. If only one (control identifier) is specified, it is assumed to be the (control definition) 
for the primary line, and the default equivalent of an (idle statement) is used for auxiliary line control. 
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TERMINAL DEFAULT STATEMENT 
Syntax 

DEFAULT 



(default terminal identifier) 



Example 

DEFAULT = TTYDFLT. 

Semantics 

Th« (terminal default statement) allows the programmer to specify the (default terminal t^tlfier) 
l \ c of default terminal attributes previously defined to be used for a (terminal definition) 
w H^e d cHp i n is incomplete. It is advantageous to group common attributes under a Default 
tZlMUcWion) and list the remaining attributes under each indiv.dua (terminal definition) . 
T e c mpilor will then refer to the Default (terminal definition) to complete the (terminal 
wX,) The (terminal default statement) is not required to appear ,n <^^{^^ 
\^"l'(termLl definition) must define all required attributes ,f a (terminal default statement) 
docs not appear. 

The {terminal default statement) can appear in a (terminal definition) or a Default (terminal 
definition) . 

Supplementary Example 

The following example illustrates how {terminal default statement)*™* be "nested" to combine the 
attributes of one or more Default (terminal definitions. 

The effect of referencing GEN ERALDEFAULT within the Default (terminal definition) TTYDEFAULT 
"Lute attributes associated with TTYDEFAULT are equivalent tc .all a tributes as defined by 
GENERALDEFAULT plus the attributes explicitly defined in TTYDbFAULl . 
If a (terminal definition^) or Default (terminal definition) references a Default (terminal definition) 
he $2^&™^ 6Lr*r* the two definitions for contradictory statements. If contradictory state- 
nwnhexW wiSSi the two definitions, the last value defined for the attribute takes precedmce In the 
examnk ^ TTY- defines the value of the PAGE attribute as 66, and the Default (termmal definition) 
lirA^ncS defmes the value of the PAGE attribute as 0. The compiler uses 66 as the value 
of the PAGE attribute for TTY2. 
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TERMINAL DEFAULT GEN ER ALDEF AU LT : 

TURNAROUND = 0. 
ICTDELAY « 0. 
TRANSMISSION^ 0. 
ADDRESS = 0. 

PAGE = 0. 

BUFFER = 0. 

TERMINAL DEFAULT TTYDEFAULT: 



-Default (terminal definition) 



DEFAULT 

BLOCK 

SCREEN 

PARITY 

SYNCS 

TIMEOUT 

MAXINPUT 

WIDTH 

ADAPTER 

CODE 

TERMINAL TTY1: 

DEFAULT 

DUPLEX 

WRU 

END 

BACKSPACE 

CONTROL 

REQUEST 

TERMINAL TTY2: 

DEFAULT 

DUPLEX 

WRU 

BACKSPACE 
CONTROL 
REQUEST [1] 
REQUEST (21 
PAGE 



GENERALDEFAULT. 
FALSE. 
FALSE. 
NULL. 
FALSE. 
3 SEC. 
72. 
72. 
4. 

ASC67. 



(terminal default statement) references 
above Default (terminal definition)s. 

"Default (terminal definition) 



TTYDEFAULT.^____ 

FALSE. 
ENQ. 

ETX (DYNAMIC). 
BS (DYNAMIC). 
CONTEND 

WRITETTY: TRANSMIT, READTTY: RECEIVE. 



( (terminal default statement) references 
~\ above Default (terminal definition) s. 



TTYDEFAULT.. 
FALSE. 



(terminal default statement) references 
above Default (terminal definitions. 



4"98" 
4"97". 

SPECIALCNTRL. „„w W 
READER: RECEIVE, WRITER: TRANSMIT. 
READPPT: RECEIVE, WRITEPPT: TRANSMIT. 
66. 
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TERMINAL DUPLEX STATEMENT 

Syntax 

DUPLEX — 1 ►TRUE 



FALSE 



Semantics 



The (terminal duplex statement) defines whether or not (TRUE or FALSE, respectively) the terminal 
type utilizes full duplex, reverse channel, or voice response features. If DUPLEX = TRUE, then the (line 
definition) for any line that has this terminal type assigned must contain the (line type statement) con- 
structs that specify full duplex. This attribute must be defined for each (terminal definition). 



5-166 



Definitions 
TERMINAL 
Terminal End Character Statement 



TI'KMINAI. INI) ( HARACTI R ST ATI Ml NT 



Syntax 



END 



( single character} 




3 



(DYNAMIC) 



Examples 



END = 4"0D\ 

END = "&" (DYNAMIC). 



Semantics 



The (terminal end character statement) defines the "end" character of the terminal type (i.e., the character 
that the terminal type would transmit to indicate an end-of-tcxt). If defined, the "end" character can be 
recognized by the DCP when RECEIVEd (in a (receive statement")), and any action to be taken can be 
specified by the programmer (using the END syntax). 

(DYNAMIC) indicates that the Message Control System of a station referencing the (terminal definition) 
is allowed to change the character for the station by means of a SET CHARACTERS (TYPE=39) 
DCWR1TE. 
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TERMINAL HOME CHARACTER STATEMENT 
Syntax 

HOME ► = . ( single character ) — : — 

Example 

HOME = 4"0C\ 
Semantics 

This statement is implemented for program documentation purposes only. It provides a means of docu- 
menting the home character of the terminal type. The documentation of this character in a (terminal 
definition) is optional. 
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TERMINAL ILLEGAL CHARACTER STATEMENT 
Syntax 

ILLEGALCHR = single character) — * 

Example 

ILLEGALCHR = 4"FF". 
Semantics 

The (terminal illegal character statement) is implemented for documentation purposes only. The docu- 
mentation of this character is not required in a (terminal definition). 



Definitions 
TERMINAL 
Terminal Inhibitsync Statement 

TERMINAL INHIBITSYNC STATEMENT 
Syntax 



INHIBITSYNC 



Semantics 



-TRUE 



FALSE- 



The (terminal inhibitsync statement") affects only terminal types that specify any of the (communication 
type number) s 17 through 27 in its (terminal adapter statement}. This statement has no affect upon, and 
need not be defined for, terminal types that do not specify any of those (communication type number)s. 

If INHIBITSYNC = FALSE, then the following occurs during a synchronous transmission. The trans- 
mission begins with the transmission of four sync characters by the adapter cluster. As the fourth sync 
character is being transmitted, the first character of the message is requested from the DCP. The DCP 
should respond to this request by supplying the first character of the transmission. As each supplied 
character is transmitted, the adapter cluster requests another character. If the DCP is unable to respond in 
time to the request, the adapter cluster transmits a sync character; this process is called "sync filling." 
Sync filling is repeated as necessary until the DCP responds with another character or the DCP directs the 
adapter cluster to "finish transmit" for the line. 

When INHIBITSYNC = FALSE during a synchronous reception, the following occurs. At the beginning of ~ ~ 

the reception, bit patterns from the line are examined by the adapter cluster and the bits discarded until a 

sync character is recognized. The recognition of a sync character establishes that the next bit to be % 

received by the adapter cluster is the first bit of the next character. The sync character is discarded, 

instead of being made available to the DCP. All characters in the transmission that are not sync characters 

are made available to the DCP. The DCP may then fetch these characters. Any sync characters received in 

the transmission are discarded. 

If INHIBITSYNC = TRUE , then the following occurs during a synchronous transmission. All actions occur 
that would occur if INHIBITSYNC = FALSE. In addition, if a sync fill is required, a "sync fill interrupt" 
occurs so that the DCP can determine when one or more undesired sync characters have been inserted into 
the transmission. System software responds to the interrupt by executing a TERMINATE ERROR. The 
controlling MCS is notified of all such situations so that corrective action (MAKE LINE READY (TYPE = 
96) DCWRITE, for example) can be taken. 

When INHIBITSYNC = TRUE during a synchronous reception, the following occurs. At the beginning of 
the reception, bit patterns from the line are examined by the adapter cluster and the bits discarded until a 
sync character is recognized. The recognized sync character is discarded, as is the next character if it is 
also a sync character. Thereafter, all subsequent characters (sync characters or otherwise) are made avail- 
able to the DCP as data. 

The reserved word SYNCS is a synonym for INHIBITSYNC. 
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Terminal Inter-Character Delay Statement 

TERMINAL INTER-CHARACTER DELAY STATEMENT 
Syntax 

ICTDELAY ► = (delay time > — ~ • 

Examples 

ICTDELAY = 0. 
ICTDELAY = 200 MILLI. 

Semantics 

The (terminal inter-character delay statement) provides the user a means to insert a timed delay between 
each character transmitted to the terminal type. The (delay time) specified defines the interval of (time} 
between the transmission of the start of one character to the start of the next character. If the time speci- 
fied is less than tlw time required to transmit a character, this statement has no effect. This attribute must 
be defined for all (terminal definition) s. 

Supplementary Example 

A Model 33 TELETYPE can receive characters at a maximum rate of one character every 100 milliseconds. If, 
for some reason, the programmer needs to insert a 1 00-millisecond delay between each character trans- 
mitted to the terminal, this can be done by specifying: 

ICTDELAY = 200 MILLI. 
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TERMINAL LINEDELETE CHARACTER STATEMENT 

Syntax 

LINEDELETE - — * < ^^ac,er) -r— I — * ' 

I — •» (DYNAMIC) — ^ 



Examples 

LINEDELETE = 4"07". 
LINEDELETE = 4" AO". 

DCWRITE. 
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TERMINAL LINEFEED CHARACTER STATEMENT 
Syntax 

LINEFEED — ► = (single character) — _ V / m - 

Example 

LINEFEED = 4"25'\ 
Semantics 

This statement is provided for program documentation only. It documents the linefeed character of the 
terminal type. The documentation of this character in a (terminal definition) is optional. 
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TERMINAL MAXINPUT STATEMENT 
Syntax 

MAXINPUT — — (integer) 

Example 

MAXINPUT = 72. 

Semantics 



The (terminal maxhwut statement) applies to unbuffered terminals and defines the maximum size text, in 
dnnc m U &nal is allowed to transmit in one message. This attribute must be defined in all 
O^^^nnSlLhi^ the (terminal buffer size statement) is not defined or is defined as 
BUFFER = NULL This statement applies only to unbuffered devices; it is meaningless to define maxin- 
put if the (terminal buffer size statement) is defined as non-NULL. 
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TERMINAL PAGE STATEMENT 
Syntax 

PAGE " " ■ < i ""' 8Cr> 

Examples 

PAGE = 0. 
PAGE =12. 



^^Z^ti^T^^^^ teimtaal ,ype be,n8 

defined has no such restrictions, then 

PAGE = 0. ^ ac 1 f^oii 

she* be specified, thus indicating that paction is T» attribute must be defined for * 

{terminal definition)*. 
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TERMINAL PARITY STATEMENT 
Syntax 



PARITY 



NULL 



TWVERTICAL- 



rEVEN r 
ODD ' 



TWHORIZONTAL- 



— |^ . j-^ EVEN -T-*" 
)J L».ODD— ' 



-*-CRC(16) 



Examples 

PARITY = NULL. 

PARITY = VERTICAL:ODD. 

PARITY = HORlZONTAL:CRC( 16). 

PARITY = VERTICAL:ODD, HORIZONTAL(0):EVEN. 

Semantics 

The {terminal parity statement} defines the type of parity checking and generation to be performed by the 
DCP when communicating with the terminal type. If the form: 

PARITY=NULL. 

is used, parity is not checked or generated. 

Hie VERTICAL option refers to the vertical parity bit of a character, and can be defined as ODD or EVEN. 

The HORIZONTAL option specifies the type of horizontal parity. If horizontal parity is a Block Check 
Character, then ODD or EVEN must be specified. If horizontal parity is a Cyclic Redundancy Check, then 
CRC( 16) must be specified. 

The or 1 option defines the function of the vertical parity bit of the Block Check Character. If this bit is 
a parity bit for the Block Check Character, then this option must be omitted or defined as (zero). If 
undefined, the option is assumed to be (zero). If the bit is to be considered as a horizontal parity bit of 
all high-order bits in the message, then this option must be defined as 1. 
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TERMINAL REQUEST STATEMENT 
Syntax 



REQUEST 




lW (request identifier -«*-R ECE1 V E — 
TW<m///c.s7 identifier)^'. -^TRANSMIT 




Examples 



REQUEST S READTTY: RECEIVE. 

REQUEST = WRITETTY :TR ANSMIT, READTTY: RECEIVE. 
REQUEST[2] = TTYTAPEIN: RECEIVE, TTYTAPEOUTrTRANSMIT. 



Semantics 



The (terminal request statement") specifies a (request identifier), or a pair of (request identifier)^ that 
designates the (request definition) to handle input from (the RECEIVE option) and/or output to (the 
TRANSMIT option) the terminal type. The (request definition) that handles input is commonly referred 
to as the Receive Request, and the (request definition) that handles output is commonly referred to as the 
Transmit Request. This statement must appear in each (terminal definition) , and cannot appear in a 
Default (terminal definition). 

The {(integet) value of 1 through 6} allows the specification of up to six pairs of Transmit and Receive 
Requests for the same device. Normally, these Request pairs differ for some application-dependent 
reasons. Only one pair of (request definitions can be the controlling (request definitions at any instant 
of time. The (request definitions in control of the terminal type immediately after DCP initialization 
has an \(integer) value of 1 through 6\of\ ; they retain control until the Message Control System (MCS) 
of a station associated with the terminal type executes a SET APPLICATION NUMBER (TYPE = 38) 
DCWRITE. 
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Terminal Screen Statement •'/*■- w' 

■ ; •.' V.». •■ » ' 
• : * V. * ••' • ' ,: •'• : ' 

TERMINAL SCREEN STATEMENT 

Syntax 

SCREEN — — -»* - ■— ■ ~^TRUE 



►FALSE 



Semantics 

The (terminal sc reen statement} defines whether or not (TRUE or FALSE, respectively) the terminal type 
is a screen (i.e., CRT) device. This attribute must be defined in each (terminal definition}. 
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TERMINAL TIMEOUT STATEMENT 
Syntax 

TIMEOUT m = » ( /wteowf //me) — , / - : " 

Example 

TIMEOUT - 3 SEC. 
Semantics 

The {terminal timeout statement) defines the interval of {time) that the adapter cluster should wait from 
the receipt of one character to the start of the next (in a (receive statement)) before assuming that the 
terminal has "timed out." The action taken upon a timeout condition can be specified in a (receive 
statement) by means of the TIMEOUT syntax. 
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TERMINAL 

Terminal Transmission Number Length Statement 

TERMINAL TRANSMISSION NUMBER LENGTH STATEMENT 
Syntax 



TRANSMISSION 



■*^NULL- 



-0 



2- 
•3- 



Semantics 

The (terminal transmission number length statement) defines the number of characters that the terminal 
Snsm te and reSvcs as the message transmission number. The and NULL options are seman ically 
equTvT ent and specify that no transmission number is used. A non-NULL transmission number length 
must be specified if I (control definition) or (request definition) that reference^ item TRAN ■ _ 
defined I for the terminal type. This statement may be omitted from a (terminal definition) if the terminal 
does not transmit or receive transmission numbers. 
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TERMINAL TURNAROUND STATEMENT 
Syntax 

TURNAROUND - = time > — — — — — . 

Examples 

TURNAROUND * 0. 
TURNAROUND = 200 MILLI. 

Semantics 

The (terminal turnaround statement) defines the time required for the terminal to shift from transmitting 
data to receiving data. The (time) defined is a parameter of a compiler algorithm for calculating the 
initiate transmit delay. Refer to the semantics of the (control definition) or (request definition) 
(initiate statement) in this chapter for more information. This attribute must be defined for each 
(terminal definition). 
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TERMINAL WIDTH STATEMENT 
Syntax 

WIDTH — — integ€r > 

Example 

WIDTH = 80. 
Semantics 




be less than or equal to the size defined in If the (terminal width 

I^Z^Z otherwise, the value of MAXINPUT is substituted by default. 
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TERMINAL WRU CHARACTER STATEMENT 
Syitta* 

WR y _ — >» < single cliaracter) -r" — — ■ t* 

L-*- (DYNAMIC) — * 



Examples 

WRU = 4"2D" (DYNAMIC). 
WRU = "?". 

Semantics 



taken can be specified by the programmer (using the WRU syntax). 
(DYNAMIC) indicates that the Me^ageContrd System of 

is allowed to change the character for |he Station by means of the SET CHARACTbRs u r rz w 
DCWRITE. 
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TKANSLATI TABU! DEI INI1 itiN 

Syntax 



TRANSLATI TABLi: ■ 



» ( translate table iden tiji 



cr \ — source size 



siring )- 



•TO- 
>TO- 



*(singlc cliaracler)- 
——^■(clestiiwtion)- 



EBCDIC — ►•TO — ^(standard character set'}-* 
-^■{standard character set)— ►•TO—*- EBCDIC — 

m (translate table identifier) 



Examples 



TRANSLATETABLE 
TRANSLATETABLE 
TRANSLATETABLE 
TRANSLATETABLE 

TRANSLATETABLE 



ATABLE 
BTABLE 
GTABLE 
DTABLE 
ETABLE 
FTABLE 
GTABLE 



TRANSLATETABLE TRANID 



8("STRING" TO "X"). 

8(4"000102" TO 4"AABBCC") 

7(4"02820B" TO 4"AACCDD"). 

7(4 k< 00" TO 4"AA"), 

8( DTABLE, 4"0P TO 4"BB"). 

8(4"00" TO 4"AA"), 

8( EBCDIC TO BCL.FTABLE, 

4"01" TO 4"BB"). 
7("1" TO 4"01'\ 

"2" TO 4"02". 

"34"TO4"0304", 

4"F5F6" TO 4"0607"). 



Semantics 



Tlie (translate table definition) allows the definition of tables that may be used in (control definition) s 
or (request definitions to translate characters of one character set to those of another character set. 

Translation tables need to be defined in an NDL program only if non-standard character sets must be 
dealt with in the Data Communications System. Terminals that transmit and receive a standard character 
set do not require a translation table definition; instead, the character set is merely named in the (terminal 
code statement') of the (terminal definition) . The character sets that do not require a (translatetable 
definition) are ASCII, BAUDOT, BCD, BCL, EBCDIC, and PTTC/6. 

The (translatetable identifier) that follows the key word TRANSLATETABLE names the translation table, 
and must be in the syntactic form of an (identifier) J .... 

(source size) defines the character size, in bits, of characters to be translated, (source size) must be an 
/integer) greater than and less than 9. 

TRANSLATION TABLE STRUCTURE 

Each clement of the translation table consists of eight bits. If N represents the (source size) , then the size 
of the table is 2 raised to the Nth power. The elements of the table are selected by an index that ranges 
from through 2 to the Nth power minus 1. 

At execution time, translation is done in the following manner. The binary weight of the low-order 

N bits of the character to be translated is used as an index into the specified translation table. The element 

of the table thus indexed is the translated result 
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INSERTING DATA INTO THE TRANSLATION TABLE 

Every translation table has a default base in which each element in the table is (all bits off). Data ean be 
nhced into the translation table by various specifications within the parentheses. If more than one 
Sednca^on a^ for a given translation table, each succeeding specification overrides, withm its scope, 
previous specifications. 
(string) TO (single character) 

This form inserts data into the translation table in the following manner. Each eigh ^ bit ^ h ^ctei^ the 
(TrinTL examined from left to right. If a character in the {string} is ; numerically greater than the s ze 
of the tabl nTentry is placed in the translation table; otherwise, the (single character) is stored uvthe 
element ^ito^lhL index is the binary weight of the N low-order bits of the (string) character 
(where N is the (source size) specified). 

(source) TO (destination) 

(source)™* (destination) must be (strings of equal length. This form of specifkation ^s^atainto 
tie Snslation table in the'following manner Translation is based upon ^corresponding characters in 

" and (destination), starting from left and proceeding to right. The first character of (source) 
Ssnonds to the first character of (destination) , the second character of (source) corresponds to the ^ 
ZZ^^lf destination),^. If a character in (pun) is numericalby g^ater^tt.es^of the 
taMe then no entry is placed in the translation table; otherwise, the corresponding character n 
^esiuZln) is stored in the element of the table whose index is the binary weight of the N low-order b.ts 
of the corresponding character in (source). 

(standard character set) TO EBCDIC and EBCDIC TO (standard character set") 

TOs form specifies a standard system software translation table from the NDL compiler ^Je 
copied into the translation table. The (standard character set)s that may be specified are- EBCDIC, 
ASC67, and BCL These forms provided way of obtaining a legitimate base upon which additional 
specifications can be made. 

(translatetahle identifier) 

This form of specification indicates that the contents of a previously defined translation table is to be 
conlS^ (translatetable identifier) mvst be the (identifier) of a previously 

^nt^ J^Zlc. This form provides a means of obtaining a legitimate base upon which additional 
specifications can be made. 

Pragmatics 

Those tables, and only those tables, that are used by a DCP reside in the local ^^^^j^^^ 1688 
a DCP does not have local memory, in which case they reside in mam system memory). Memory tor 
translation tables is allocated in blocks of 256 words, regardless of the space required for those tables . 
Tables are densely packed and all elements are used before another block of 256 words is allocated. Unless 
con ^ideSionTJven to the translation requirements of devices in the data communications system while m 

SanS ♦ m 

S3 is teyonif the scope of this manual to describe the planning of a data commumcations system, 

this fact should not escape the NDL programmer. 



5-185 



Definitions 
TRANSLATETABLE 
Continued 



Supplementary Examples 
Example 1* 

TRANSLATETABLE AT ABLE 8( "STRING" TO "X"). 

Character to be Translated Result 



"S" 
"R" 

44 j»» 

"N" 
"G" 



"X" 
"X" 
"X" 
"X" 
"X" 
"X" 



ATABLE is a translation tabic containing 256 elements. The (source size) , 8 in this example, deter- 
mine! > the table size. All character from (source} are translated to the (single character) . 

Example 2 

TRANSLATETABLE BTABLE 8(4"000102" TO 4"AABBCC") 

Character to be Translated Result 



4"00' 

4"or 

4"02' 
4"03' 



4"AA" 
4"BB" 
4"CC" 
4"00" 



rtaRI F contains 256 elements. C haracters from 4"000102", are translated to the 

^S^^^u. <*.««*»>. ^V 8 ^ 1116 character 4 " 03 " * translat t0 

4"00" because there is no specification in (source) for 4 03 . 
Example 3 

TRANSLATETABLE CTABLE 7(4"02820B" TO 4-AACCDD'). 

Character to be Translated Es§n!i 



4"oi M 

<t"fi2" 4"AA" 

4«82" 4 AA 
4"0B" 



4"00 r 
4"AA 
4"AA 
4"DD' 



In thisexample, the translation table {TABLE contains 128 elements. The ch aracter 4"01" is 
rans toted ^to^V character, because 4"01" is unspecified in the (source) The character 4 82 is 
t r rstotedto?he^d 
the translation table. 

Example 4 

TRANSLATETABLE DTABLE 8(4* W TO 4"AA"). _ 

ETABLE 8(DTABLE, 4 4< 01 TO 4 BB ). 

The above (translatetable definition) defines two translation tables: DTABLE ^ ^" t . 
elements in DTABLE contain 4'W, except the element indexed by the character 4 00 , that element 
comains ?4"AA'\ ETABLE specifies DTABLE as a base, and then modifies that base with a subsequent W 
specification. 
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Example 5 

TRANSLATETABLE FT ABLE 8(4**00" TO 4**AA"), 

GTABLE 8(EBCDIC TO BCL, FT ABLE, 4**01 " TO 4**BB"). 

GTABLE is defined to contain 256 elements, and specifies the standard EBCDIC-to-BGL translation 
table upon which subsequent specifications modify. FTABLE also contains 256 elements and 
appears as a specification in GTABLE. Since each succeeding specification overrides within its scope 
any previous specification, FTABLE in effect overlays all elements. The result is the same as if only 
the following had appeared: 

TRANSLATETABLE FTABLE 8(4**00" TO 4**AA"), 

GTABLE 8(FT ABLE, 4**01" TO 4**BB"). 

The above example points out that any table appearing as a specification indicates all elements of that 
table, not just those elements explicitly defined. The example is not intended to illustrate an accept- 
able programming practice. 
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6. VARIABLES 

GENERAL 

The NDL compiler does not allow a programmer to declare and use program variables, as do other language 
compilers such as ALGOL, PL/I, and COBOL. Instead, the NDL programmer can use only predefined 
program variables. 

The (bit variable) s and (byte variable).? are the two types of variables the programmer can use. The (bit 
variables- me one-bit variables that can only assume logical values (i.e., TRUE or FALSE). The W<? . 
variable) s are all eight-bit variables, and can assume integer values from through 255, except for the 1R 
variable, which is a 10-bit variable. The IR variable is included as a (byte variable) as a matter of 
convenience. 

Individual bits of a (byte variable) can be referenced and used like a (bit variable) , if referenced in the 
form illustrated below. 



( byte variable ) — — [ (bit number) — ► ] — — — — 

where (bit number) is an (integer) not greater than the number of bits contained in the variable minus 1 . 
For example, bit 5 of IR is referenced as IR[5] . 
FUNCTION OF VARIABLES 

Functionally, variables fall into one of three general categories: 

a. Variables that are available to the programmer for general information storage. 

b. Variables that can be used for system/station communication. 

c. Variables that contain control information. 

General information variables can be used within their scope by the programmer for data storage, calcula- 
tions etc Additionally, some variables in this category could (by convention) be used as communication 
paths between (request definitions executing on a given line. (The use of a given variable for this appli- 
cation is restricted by the scope of that variable.) 

Variables whose intended function is communication to and from the main system and stations are gener- 
ally contained in the message header of a message sent to the main system from a station, or sent to the 
station from the main system. Messages from the main system to a station are originated either by the MCS 
or by an application program (via the I/O Intrinsics). 

The format of message variables within a message header is described in detail in the B 670 0/ B 7700 
DCALGOL Reference Manual . Generally, message variables are contained in five fields of the message header: 

a. Message Toggles (word [ 1 ] .[39:8] ) 



b. Message Tallys (word [3] .[23:24] ) 
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c. Message Error Flags (word 1 1 1 .[23:24] ) 

d. Variant "Carriage Control" (word [01 |39:16l) 

e. Message Retry Count (word | 2| . |47:8 | ) 

Message Toggles and Message Tallys provide storage area in the header for some of the station general infor- 
mation variables. The meaning of values stored in these fields must be established by mutual convention be- 
tween the MCS writer and the NDL programmer. 

Message Error Flags are used for the station to communicate to an MCS that some exceptional event has 
occurred in a (request definition) or (control definition). These variables reference bits in the message 
header of "result" messages returned to the MCS as a result of execution of a (terminate statement). 

Carriage Control is valid for Transmit Requests, and provides information regarding the kind of carriage 
control to be performed by a Transmit Request. These variables reference bits or bytes in the message 
header of WRITE (TYPE=33) DCWRITE messages. 

The Message Retry Count is described under RETRY in this chapter. 

Variables whose function is to contain control information are used by both the DCP operating system and 
the programmer. Generally, these variables provide information to control the logic paths of (control 
definitions, (request definition's, and the DCP operating system. 

SCOPE OF VARIABLES 

The scope of the variables in NDL is described as being: 

a. Station-oriented. 

b. Line-oriented. 

c. Global. 

Station-oriented variables exist lor each station in the network. TALLY [0] is an example of a station- 
oriented (byte variable); thus, each station has its own TALLY [0] . The variables of a given station are 
visible to a line only while STATION is set to that station's "station index." 

Line-oriented variables exist for each line on a DCP. The variables of a given line are visible to every station 
assigned to that line. MAXSTATIONS is an example of a line-oriented variable. Each line on a DCP has its 
own MAXSTATIONS, and every station assigned to a given line can access the MAXSTATIONS variable of 
that line. 

A global variable is a variable that is visible to all stations on a DCP. 
DESCRIPTION OF VARIABLES 

The remainder of this chapter contains descriptions of each (bit variable) and (by te variable) . The variables 
(listed in table 6- 1 ) are described in alphabetical order. The name of the variable precedes a summary of the ^ 
variable characteristics, followed by a detailed description of the variable. 
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The summary of the variable characteristics includes the places iit the source program that the variable can 
be interrogated or altered, and the size, in bits, of the variable. In the summary, the word "Interrogate" 
indicates that the programmer can interrogate the variable. The word "Alter" indicates that the programmer 
can use the (bit variable) j (byte variable) as aii (assignable bit variable) / (assignable byte variable). The 
corresponding letters "C\ *T'\ and "R"m the summary refer to (control definition) , Transmit Request, 
and Receive Request, respectively. The last item to appear in the summary is the size, in bits, of the variable. 
If no size is defined, then the size of the variable is one bit. 

For example, the summary : 

EXAMPLE 1 

Interrogate, CTR, 8 

can be expanded as follows: 

EXAMPLEl is an 8-bit variable. It can be 
interrogated in a (control definition). 
Transmit Request, or Receive Request. 

The summary: 

EXAMPLE2 

Interrogate/ Alter, CTR/TR 

can be expanded as follows: 

EXAMPLE2 is a (bit variable). It can be 
interrogated in a (control definition) , 
Transmit Request, or Receive Request. 
Additionally, EXAMPLE2 can be altered 
(i.e., appear as an (assignable bit variable)) 
in a Transmit Request or Receive Request, 
but not in a (control definition) . 

Table 6- 1 contains the summaries of each variable for quick reference. 
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Table 6 -1. Table of Variables 



NAME 


SIZE 
(in bits) 


INTERROGATE 


ALTER 


ADDER R 




f^TR 


C1K 


AI 


B 

o 


tlK 


CTR 


AUX (LINE (BUSY)) 




CTR 

v> x ix 


Vvl Ix 


AUX (LINE (QUEUED)) 




A_/ 1 Ix 


tlK 


AUX (LINE (TALLY \\0 or 1\] 


8 


CI K 


CTR 


AUX (LINE (TOG \\0vrl\] 




CiK 


CTR 


BCC 


8 


CI K 


CTR 


BCCERR 




TR 

A IX 


TR 
1 Ix 


BLOCK 




T 




BLOCKED 




T 
I 




BREAK (RECEIVE) 




CTR 


CTR 

1 IX 


BREAK [TRANSMIT | 




CTR 


CTR 

1 XX . 


BUFOVFL 




CTR 


fTR 

V^ l XX 


CARRIAGE 




T 




CHARACTER 


8 


CTR 


CTR 

X XX 


CONTROLFLAG 




TR 

• • A IN 


TR 

1 IX 


CRC 




CTR 


PTR 

1 IX 


CRC\\() or l\] 


8 


CTR 

vl I\ 


PTR 
Vl Ix 


CRCERR 




TR 


TR 

1 IX 


DISCONNECT 




TR 

x XX 


TR 

1 IX 


ENDOFBUFFER 




IK 


TR 


FORMATERR 




1 Ix 


IK 


INHIBITSYNC 




Cllx 


CTR 


IR 


10 


CTR 








CTR 


CTR 


LINE (QUEUED) 




CTR 


CTR 


LINE (TALLY \\0 or l\\ 


8 


CTR 


CTR 


LINE(TOG|{0or/}l 




CTR 


CTR 


LINEFEED 








LOSSOFCARRIER 




CTR 


CTR 


MAXSTATIONS 


8 


CTR 




NAKFLAG 




TR 


TR 
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Table 6- 1 . Table of Variables (Cont) 



KI A Ail 17 


SIZE 

{ill DllSj 


1JN 1 liKKUuA 1 Cj 


AT TPP 


NAKONSELECT 




TR 


TR 


NOSPACE 




CTR 




PAGE 




T 




PAPERMOTION 




- T 




PARITY 




CTR 


CTR 


RETRY 


8 


CTR 


CTR 


SEQERR 




TR 


TR 


SEQUENCE 




CTR 


CTR 


SKIP 




T 


_ 


SKIPCONTROL 


8 


T 


• 


SPACE 




T 




STATION 


8 ■ 




" C : • 


STATION (ENABLED) 




CTR 




STATION (FREQUENCY) 


8 


CTR 




STATION (QUEUED) 




CTR 


. " 1 


STATION (READY) 




CTR 


' .. . ■ 


STATION (TALLY) 


8 


CTR 


CTR 


STATION (VALID) 




CTR 




STOPBIT 




CTR 


CTR 


SYNCS 




CTR 


CTR 


TAB 




T 




TALLY I (tally number) ) 


8 


CTR 


CTR 


TIMEOUT 




CTR 


CTR 


I {toggle numoer y\ 




CTR 


CTR 


TOGS 


8 


CTR 


CTR 


TRANERR 




TR 


TR 


WRUFLAG 




TR 


TR 
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ADDER R 

Interrogate/Alter, CTR/CTR 

ADDERR references bit 8 in the Error Flag Field of a message header, and normally indicates that an address 
character error has occurred while executing a (receive statement). Refer to the ADDRESS option of the 
(receive statement). 



AI 

Interrogate/Alter, CTR/CTR, 8 

This variable addresses a volatile register and should not be used for data storage. Its main purpose is to 
allow access to the untranslated byte just received rather than to the translated byte in CHARACTER, 
particularly when executing the (sum statement). 



AUX(LINE(BUSY)) 

Interrogate/Alter, CTR/CTR 

AUX(L1NE(BUSY)) is used to allow or inliibit the interruption of the execution of a (control definition) 
or (request definition) on the auxiliary line of a full duplex line pair. If this bit is TRUE, it indicates to the 
DCP operating system that the line is engaged in functions that must not be interrupted. If FALSE, it indi- 
cates to the DCP operating system that the line can be interrupted to initiate another function. 
AUX(LINE(BUSY)) is line-oriented, but may be altered only by the auxiliary line. Both the auxiliary and 
primary line may interrogate this bit. 

A (control definition) or (request definition) will be interrupted when AUXfLINE(BUSY)) is FALSE if 
the primary line executes a (fork statement). (Note that an interruption causes control to leave a (control 
definition) or (request definition) , and that control is not returned to the point where the interruption 
occurred.) AUX(LINE(BUSY)) is set TRUE by system software when: 

a. The primary line executes a (fork statement) and AUX(LINE(BUSY)) is FALSE or 

b. The auxiliary line (control definition) is entered, or 

c. The auxiliary line enters a Receive or Transmit Request. 

If AUX(LINE(BUSY)) is TRUE when the primary line executes a (fork statement), the (fork statement) 
will act as a no-op. 
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Variables 
Continued 



AUX(LINE(QUEUED)) 

Interrogate/Alter, CTR/CTR 

This is a line-oriented (bit variable) that refers to the queued status of the auxiliary line of a full duplex line 
pair. The bit is set by the DCP operating system if and when an input message space is explicitly acquired 
by executing a (getspace statement) on the auxiliary line. 



AUX(LINE(TALLY[(0 or J \ ] )) 

Interrogate/ Alter, CTR/CTR, 8 

These are line-oriented (byte variable)s for the auxiliary line of a full duplex line pair, and can be used for 
any purpose by the NDL programmer. They can be accessed by either the primary or auxiliary line at any 
time. 



AUX(LINE(TOG [ \0 or 1 \ ] )) 
Interrogate/Alter, CTR/CTR 

These are line-oriented (bit variable) s for the auxiliary line of a full duplex pair, and may be used for any 
purpose by the NDL programmer. They may be accessed by either the primary or auxiliary line at any time. 



BCC 

Interrogate/Alter, CTR/CTR, 8 

BCC is used by system software for the purpose of accumulating a Block Check Character when a station 
(terminal definition) defines horizontal parity as ODD or EVEN in the (terminal parity statement) . 

Block Check Character accumulation is an automatic function, if appropriate, of the (receive statement) 
and (transmit statement). Block Check Character accumulation is based upon execusive-OR logic, that is, 
as characters are received or transmitted, they are exclusively OR-ed with the contents of BCC. It is the 
responsibility of the programmer to initialize BCC when appropriate. (Refer to the (initialize statement) 
under (request definition) or (control definition).) 

If a station (terminal definition) does not define horizontal parity , BCC can be used as a temporary data 
storage area. It should be pointed out, however, that the value in BCC is destroyed by most constructs of 
the (terminate statement). Furthermore, since the intended purpose of BCC is to contain parity information, 
BCC and CRC[01 address the same data space. BCC cannot be used if a terminal uses Cyclic Redundancy 
Check. 

When accumulating a Block Check Character, a convenient means to eliminate a specific character from the 
value accumulated in BCC is the (sum statement). 



Variables 
Continued 



BCCERR 

Interrogate/ Alter, CTR/CTR 



BCC option of the (receive statement). 



BLOCK 

Interrogate, T 



This bit references bit *>9 in word zero of a message header. If TRUE, this bit indicates that more > blocks (or 
J^?oVi"^ are to follow. Use of this bit implies a conventton between the MCS and 

the NDL programmer for the purposes of providing blocked transmissions. 

BLOCK is set TRUE implicitly as a result of execution of a TERMINATE BLOCK construct in a Receive 
Request. 



BLOCKED 

Interrogate, T 

A synonym for BLOCK. Refer to BLOCK. w ^ 



BREAK I RECEIV E] 

Interrogate/ Alter, CTR/CTR 



statement). 

No.e <„a. if bi. is TRUE in a « <° 

EVENT (CLASS=1) message. Refer to the B 6700/p 7 /uu uialwl Ldusuas — 

information regarding this message. 



BREAK [TRANSMIT] 

Interrogate/Alter, CTR/CTR 



of the (transmit statement). 

w„to th,t if tlm bit is TRUE in a message to be returned to the MCS, the message is returned as a STATION 
EVENT (C LASS=1) mcsfag. Ref'To the B 6700/B 7700 DCALGOL Language Reference Manual for more 
information regarding this message. 



6-8 



Variables 
Continued 



BUFOVFL 

Interrogate/Alter, CTR/CTR 

Tlus (bit variable) refers to bit 2 in the Error Flag Field of a message, and normally indicates that a cluster 
buffer overflow condition occurred while executing a (receive statement). Refer to the semantics under the 
BUFOVFL option of the (receive statement). 



CARRIAGE 

Interrogate,! 

CARRIAGE is a carriage control variable, and is used to indicate if a carriage return is desired at the comple- 
tion of the text transmission. 

CARRIAGE is TRUE if message word [0] . [25:1] is zero. 

Tlus bit can be set by the I/O Intrinsics for a data communications file, or by the MCS. 



CHARACTER 

Interrogate/Alter, CTR/CTR, 8 
CHARACTER is a line-oriented (byte variable). 

CHARACTER contains the last character TRANSMITted or RECEIVEd on the line, unless otherwise altered 
by a (fetch statement) or an (assignment statement). 



CONTROLFLAG 

Interrogate/Alter, CTR/CTR 

Tlus (bit variable) refers to bit 12 in the Error Flag Field of a message, and normally indicates that the 
station defined control character was received. Refer to the CONTROL option of the (receive statement). 

Note that if this bit is on in a message to be returned to an MCS, and the first character of the message is the 
control character of the station, the message is returned as a STATION EVENT (CLASS=1). Refer to the 
B 6700/B 7700 DCALGOL Language Reference Manual for more information regarding this message. 



CRC 

Interrogate/Alter, CTR/CTR 

In (request definition)^ and (control definition^ that use the Cyclic Redundancy Check, system software 
tests the status of the (bit variable) CRC before the execution of any (receive statement) or (transmit 
statement). If CRC is TRUE, the byte (or bytes) transmitted or received are calculated into the Cyclic 
Redundancy Check stored in the (byte variable)s CRC[0] and CRC[1 ] . If CRC is FALSE, bytes transmit- 
ted or received do not affect the Cyclic Redundancy Check. 



Variables 
Continued 



CRC[{0orl\) 

Interrogate/Alter, CTR/CTR, 8 

System software uses the (byte variable)s CRC[0] and CRC[1] as a concatenated 16-bit information field 
to contain Cyclic Redundancy Check information for those stations whose (terminal definitions define 
horizontal parity as CRC(16). If the (bit variable) CRC is TRUE, Cyclic Redundancy Check calculation is 
done using CRC [0 ] and CRC[1 J as a 16-bit field, and the characters TRANSMlTted or RECElVEd. If CRC 
is FALSE, Cyclic Redundancy Check calculation is inhibited. 

If a station (terminal definition) does not define horizontal parity, then CRC[0] and CRC[1] can be used 
as a temporary storage area. It should be pointed out, however, that the values in CRC[0] and CRC{1] are 
destroyed by most constructs of the (terminate statement). Additionally, since the intended purpose of 
these variables is storage of parity information, CRC[0] and BCC address the same byte. CRC[0J 
cannot be used for temporary data storage if the (control definition) or (request definition) uses BCC for 
Block Check Character accumulation. 



CRCERR 

Interrogate/Alter, CTR/CTR 

CRCERR references bit 7 in the Error Flag Field of a result message, and conventionally indicates that an 
error in the Cyclic Redundancy Check occurred while executing a (receive statement). Refer to the seman- 
tics of the CRC option of the (receive statement). 




DISCONNECT 
Interrogate/ Alter, TR/TR 

DISCONNECT references bit 12 in the Error Flag Field of a riiessage, and indicates that a disconnect occur- 
red on the line while executing a (request definition). 



ENDOFBUFFER 

Interrogate/Alter, TR/TR 

ENDOFBUFFER references bit 17 in the Error Flag Field of a result message, and is conventionally used by 
a (request definition) to indicate when an overflow of the text buffer has occuited. Refer td the semantics 
of the ENDOFBUFFER option of the (receive statement). 



FORMATERR 

Interrogate/Alter, TR/TR 

This bit references bit 10 in the Error Flag Field of a result message* and is conventionally used to indicate 
that a format error occurred while executing a (receive statement). Refer to the REGEIViE (string) construct 
of the (receive statement). 
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Variables 
Continued 



INHIBITS YNC 

Interrogate/Alter, CTR/CTR 

INHIBITSYNC is a line-oriented variable that causes actions as described under the (terminal inhibitsync 
statement). 



IR 

Interrogate, CTR, 10-bit 

IR addresses the 10-bit Input Register of the adapter cluster. This register contains hardware related control 
and data information for a line adapter. 

IR can be interrogated using a (bit number) specification, (bit number)s for IR range from zero through 9. 
For example, IR[0] addresses bit number zero of the Input Register. 

Refer to the Burroughs Data Communications Processor Reference Manual or the DCP Reference Card for 
the meaning of the bits in IR. 



UNE(BUSY) 

Interrogate/Alter, CTR/CTR 

UNE(BUSY) is a line-oriented control information bit, and is used to allow or inhibit the interruption of 
the execution of a (control definition) or (request definition) on a single line. In the case of a full duplex 
line pair, LINE(BUSY) refers to the primary line. If this bit is TRUE, it indicates to the DCP operating 
system that the line is engaged in functions that must not be interrupted. If FALSE, it indicates to the DCP 
operating system that the line can be interrupted to initiate another function. LiNE(BUSY) can be altered 
only by the primary line of a full duplex line pair. 

A (control definition) or (request definition) is interrupted when LINE(BUSY) is FALSE if the DCP re- 
ceives in its Request Queue a station-oriented DCWR1TE message, and STATION(QUEUED) is FALSE for 
that station. If the message is a READ - ONCE ONLY (TYPE=34), STATION is set to that station index, 
and control is transferred to the Receive Request for that station. If the message is a WRITE (TYPE=33) 
DCWRITE message, STATION is set to that station index, and control is transferred to the Transmit Request 
for that station. If the message TYPE is neither of the above, the function associated with the message is 
executed and control resumes at the beginning of the line (control definition) , witn the value of STATION 
equal to the index of the station for which the function was initiated. (Note that an interruption causes con- 
trol to leave a (control definition) or (request definition), and that control is not returned to the point where 
the interruption occurred.) 



Variables 
Continued 



LIN E( BUSY) is set TRUE by system software when: 
u. The (control definition) is entered, 

b. A (request definition) is entered, or 

c. The line is the primary of a full duplex line pair, LINE;(BUSY) is FALSE, and the auxiliary line ex- 
eeutes a (fork statement). 

Note that if LINE(BUSY) is TRUE when the auxiliary line of a full duplex line pair executes a (fork state- 
ment) , the (fork statement) acts as a no-op. 



LINE( QUEUED) 
Interrogate/Alter, CTR/CTR 

LINE(QUEUED) is a line-oriented variable used to indicate whether or not (TRUE or FALSE, respectively) 
a message has been queued for any station on the line. It is set TRUE by system software when a message 
is inserted into an empty Station Queue of a station assigned to the line. It is the programmer's responsibil- 
ity to set it FALSE when appropriate. 



LIN E(T ALLY [jo or / }| ) 

Interrogate/Alter, CTR/CTR, 8 

L1NE(TALLY l| or 1 \] ) are line-oriented variables for data storage, etc., available to the programmer. 

An MCS may dynamically alter the line tallies by performing a SET/RESET LINE TOG/TALLY (TYPE=1 03) 
DCWRITE request. 



LINE(TOGl{0 orl\]) 
Interrogate/Alter, CTR/CTR 

LINE(TOGl| or are linje-oriented variables for general information storage, etc., available to the pro- 
grammer. 

An MCS may dynamically alter the line toggles by performing a SET/RESET LINE TOG/TALLY (TYPE=103) 
DCWRITE request. 



LINEFEED 

Interrogate, T 

LINEFEED is a carriage control variable and is TRUE whien message word [0] . [24: 1 ] is zero. If TRUE, 
LINEFEED indicates that a new line is required at the completion of the text transmission. This bit can be 
set by the I/O Intrinsics for a data communications file, or by the MCS. 



Variables 
Continued 



LOSSOFCARRIER 

Interrogate/Alter, CTR/CTR 

LOSSOFCARRIER references bit 18 in the Krror Flag Field of a result message, and is conventionally used 
to indicate that a loss of carrier occurred while executing a (receive statement) . Refer to the 
LOSSOFCARRIER option of the (receive statement). 



MAXSTATIONS 

Interrogate, CTR, 8 

MAXSTATIONS is a line-oriented (byte variable) whose value is the maximum number of stations that can 
be assigned to the line. 

MAXSTATIONS is initialized to the value defined in the (line maxstations statement) of the (line defini- 
tion). If the (line maxstations statement) does not appear in a (line definition) , then MAXSTATIONS is 
initialized to the number of stations listed in the (line station statement). If neither statement appears, 
MAXSTATIONS is zero. 

Within a (control definition) , the valid range of values which may be assigned to the (byte variable) STATION 
is between zero and MAXSTATIONS -1 , inclusive. 



NAKFLAG 

Interrogate/Alter, TR/TR 

NAKFLAG references bit 1 1 in the Error Flag Field of a result message, and conventionally indicates that a 
transmission was NAKed by the terminal. This bit is not set by system software, and its use is at the option 
of the programmer. 



NAKONSELECT 

Interrogate/Alter, TR/TR 

NAKONSELECT references bit 16 of the Error Flag Field of a result message, and is conventionally used to 
indicate that a Transmit Request was NAKed when it attempted to select the terminal. This bit is not set by 
system software, and its use is at the option of the programmer. 



NOSPACE 

Interrogate, CTR 

NOSPACE is a global variable that, when TRUE, indicates that a "no space" condition exists in the available 
space pool. NOSPACE is set by system software when the condition exists, and reset when the condition no 
longer exists. 



Variables 
Continued 



PAGE 

Interrogate, T ^ . 

PAGE is a «*p con.ro, varia„,e. and ^^^^^^^^^ 

PAPERMOTION. 

PAGE is set TRUE is message word 1 1 . 1 26 : U = 1 . 



PAPERMOTION 

Interrogate, T . 
PAPERMOTION isa carriage con.ro, vari* .ha. ^^^o^.r^SSS^ 

after the text is transmitted. 



PARITY 

Interrogate/Alter, CTR/CTR . . ; 



RETRY 

Interrogate/ Alter, CTR/CTR, 8 

RETRY is a station-oriented variable, and is referred to as DCP RETRY. 
The Purpose of DCP RETRY is to record the 

munU with a terminal but ftW as unsuccessful attempt at an operate 

programmer decrements RETRY (x.c. UCF Km kiw 

until RETRY equals zero, then executes a TERMINATE, hkk 

^ nrp RFTRY is implicitly set to an initial value called 

dS^of^^&RY is specified oy .he NDL program in .he 

(station retry statement). 

the value assigned to DCP 1N1 1 1AL Rti * i , a /. te * tort re frv statement) assigned to DCP -IN" 

Message Retry Field is 255, the va lue specified !^ at M'^SS to DCP INITIAL RETRY. The NDL 
'rETRY, ^^^^^^^^^^ScP INITIAL RETRY at any time by ex- 

SnTt^ t , 
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Continued 



SEQERR 

Interrogate/ A Iter, TR/TR 



SEQERR references bit 1 4 in the Error Flag Field of a result message, ^^^^^^^ 
sequence number overflow occurred as the result of the execution of an INCREMENT SEQUENCE, con 
struct. Refer to the (increment statement). 



SEQUENCE 

Interrogate/Alter, CTR/CTR 



SEQUENCE is a station-oriented bit that indicates whether or not (TRUE or FALSE respectively) a 
fe^demiL) is to perform automatic sequencing. SEQUENCEis controlled by a SET/RESET 
SEOUENCE MODE (TYPE=49) DCWR1TE from the MCS. SEQUENCE can be set FALSE by the ND L 

cln Z set TRUE only by the controlling MCS^ SEQUENCE be ffi^&t^ 
(request definition) for a terminal employs sequence number constructs such as T^^" 
INCREMENT SEQUENCE, and STORE SEQUENCE. Use of automatic sequencing is the opt»on and res- 
ponsibility of the NDL programmer. 



SKIP 

Interrogate/T 

SKIP is a carriage control variable. SKIP is used in conjunction with SS^^l^^^L 
channel N" on an output device. If message word [0]. 27:1] = 1 , SKIP is set TRUE and SKIPCONTROL 
^iV3i!i5?uii.ber to skip to. Both SKIP and SKIPCONTROL can be set by the I/O lntnns.es 
for a data communications file, or by the MCS. 



SKIPCONTROL 

Interrogate, T, 8 



SKIPCONTROL is used in conjunction with the (bit variable) s SKIP and SPACE. If SKIP is TRUE, then 
^PCO^ROLapStoSK^ If SPACE is TRUE, SKIPCONTROL applies to SPACE Ifneitherare 
ffSSEled. Both SKIP and f ACE " 

description of the function of this byte, refer to SPACE and SKIP. SKIPCONTROL is transierrea 19 in c 
STC in"he message headed of a WRITE (TYPEr33)- DCWRITEm message word [0] .[39.81 , 
and can be set by the I/O Intrinsics for a data communications file, or by the mu>. 



SPACE 

Interrogate, T 



SPACE is . carria^ contro. variable. SPACE ^S^^^StK 

data communications file, or by the MCS. 
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Continued 



STATION 

Interrogate/ Alter, C/C, 8 

STATION is a iine-orieo.cd (^y ,e ! M ^ k ) '^ '""S'^^[^ e J^^^^J^^^^»^ } '^^^' 
value associated will. Hie station must be stored .n STATION. 

A s,a,.o„ Mo» vaiue is associated wijh caei, ^^^X^Uonl^'^^ 
After DCP Wi.to.ion. an MCS can 

as ^at:. b =:^ 

tion by interrogating the STATION(VALID) (bit variable). 

Tbere is a — vaiid station index ^^^^^^ ^SS^' 
MAXSTATIONS. 

STATION(ENABLED) 

Interrogate, CTR 

Tbisisastation.ricnted^^ 

SSSSK^ rs"SisaSfS^ ...empts «o invoKe the Receive Re- 

quest will be disallowed. 

(TYPE=36) DCWRITE. 

STATION(FREQUENCY) 

Interrogate. CTR. 8 

STATIONCFREQUENCY, is a scented <W e ^ 
(TYPE=35 ) DCWRITE. Refer to the (station frequency statement/. 
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Continued 



STATION(QUEUED) 

Interrogate, CTR, 8 



STATION(QUEUED) is a station-oriented variable that indicates whether or no (TRUE ^4r£bieis 
SeW tSe are any messages (output or enableinput) in the sta ion queue. Note that if tlm variable is 
FALSE tl e execution of an INITIATE REQUEST construct acts as a no-op. 



STATION(READY) 

Interrogate, CTR 



If STATION(READY) is TRUE, the station associated with the station ' indexstjjd ijM|«gj n 
c™ y N No function (e.g a Transmit ■ » £3^^ KteS^M 
if it is not ready. Stations can become n*^/* ^result ^"^gjg STATION NOT-READY 
in one of its (request definitions or as the result of the MCS executing a make 



(TYPE=37) DCWRITE. 



STATION(TALLY) 

Interrogate/Alter, CTR/CTR, 8 



i , STATION (TALLY) is a station-oriented {byte variable) and '^^^^j^^^^^^j^^^^^^ 

^ used bv the NDL program for data storage. The initial value of P ATI0N(T * L ^ Y J"" e ixoRFd in a 

^ ^TIOWiOLY) differs from TALLY [(tally number)) in that it cannot be directly STOREd a 



message header. 



STATION(VALID) 

Interrogate, G 



T*e STATION^) bit — 

associated with the station index value stored in STATION, Reter to tne ^ oyie varmu / 



STOPBIT 

Interrogate/Alter, CTR/GTR 



STOPBIT references bit 1 in the Error Flag Field of a result message , and ^^^^^e 
sto^bi "rror was detected while executing a (receive statement). Refer to the STOPBIT option of the 

(receive statement). 



SYNCS 

Interrogate/Alter, CTR/CTR 



SYNCS is a synonym for INMBITSYNC. Refer to the INHIBITSYNC description. 
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Continued 



TAB 

Interrogate. T 



TAB is a carriage control variable, and is conventionally used to indicate tabulation for the terminal. This 
bit is not set by I/O Intrinsics, and its use implies some established convention between the MCS and the NDL 
programmer. TAB is set TRUE if message word [0 1 .[30: 1 1 - 1. 



TALLY [(tally number)] 
Interrogate/Alter, CTR/CTR, 8 

TALLY [0] , TALLY [1] , and TALLY [2] are general purpose station-oriented (byte variable)s. They can 
be used for storage of 8-bit quantities such as counters, characters, etc. When the DCP is initialized, the 
TALLYs are initially zero unless a value is specified in a (station initialize statement). TALLYs may be 
initialized directly from a message header (message word [3] .[23 :24] ) by utilizing the INITIALIZE 
TALLY {(tally number) | construct, thereby enabling an MCS to supply additional information to the DCP. 
The DCP can likewise transfer the value of a TALLY back to an MCS in a result message by utilizing the 
(store statement). Once a TALLY has been assigned a value, that TALLY retains that value until explicitly 
altered by the NDL program. 



TIMEOUT ^ 
Interrogate/Alter, CTR/CTR 

TIMEOUT references bit (zero) of the Error Flag Field in a result message, and conventionally indicates 
that a timeout occurred while executing a (receive statement). Refer to the TIMEOUT option of the 

(receive statement). 



TOG {(toggle number)] 
Interrogate/Alter, CTR/CTR 

TOG [0] through TOG [7] are general purpose station-oriented (bit variable) s, often referred to as toggles. 
They can be used for storage of logical values (TRUE and FALSE). When the DCP is initialized, the value of 
the toggles is set to the value specified in the (station initialize statement) , or, if such initialization is not 
specified, the initial value will be FALSE. Toggles can be assigned a value directly from a message header 
(message word [ 1 ] .[39:8] ) by utilizing the INITIALIZE TOG [ (toggle number)] construct. Toggles can 
be stored into a result message by utilizing the (store statement): Once a toggle has been assigned a value, 
that toggle retains that value until explicitly altered by the NDL program. 



TOGS 

interrogate/Alter. CTR/CTR, 8 

TOGS addresses the eight (bit variable)s TOC[01 through TOG [71 . For example, TOGS = 4"FF" sets 

TOG[0| through TOG [71 TRUE. TOG [01 is considered the low-order bit, and TOG [71 the high-order w 

bit. — 
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Variable* 
Continued 



TRANERR 

Interrogate/Alter, CTR/CTR 

TRANERR references bit 9 in the Error Flag Field of a result message, and is conventionally used to indi- 
cate that a transmission number error occurred. Refer to the TRAN option of the (receive statement). 



WRUFLAG 

Interrogate/Alter, CTR/CTR 

WRUFLAG references bit 1 3 in the Error Flag Field of a result message. If this bit is TRUE upon termina- 
tion of a (request definition) , the result message is returned to the MCS as a STATION EVENT (CLASS = 1 ) 
message. Refer to the B 6700/B 7700 DCALGOL Language Reference Manual for more information regard- 
ing this message. 
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APPENDIX A. RESERVED WORDS 



The following is a complete list of reserved words used in the Network Definition Language. These words 
have special meaning to the compiler and cannot be used as (identifiers or in any manner other than their 
defined meaning. Any synonym of a reserved word is shown adjacent to the word, in parentheses. 



ABORT BLOCKED (BLOCK) 

ADAPTER (ADAPTOR) BREAK 

ADAPTOR (ADAPTER) BUFFER 

ADDERR BUFOVFL 

ADDRESS BUSY 

Al CARRIAGE 

ALTERNATE CHAR (CHARACTER) 

ANSWER CHARACTER (CHAR) 

ASCII CLEAR 

ASC63 CLUSTERS 

ASC67 CODE 

ASC68 CONNECTION 

AUX (AUXILIARY) CONSTANT 

AUXILIARY (AUX) CONTINUE 

BACKSPACE (BKSP) CONTROL 

BAUDOT CRC 

BCC CRCERR (BCCERR) 

BCCERR (CRCERR) DCP 

BCD DEFAULT 

BCL DEFINE 

BEGIN DELAY 

BINARY DIALIN 

BKSP (BACKSPACE) DIALOUT 

BLKN DIFFERENT 

BLKNERR DIRECT 

BLOCK (BLOCKED) DISCONNECT 



RESERVED WORDS (Cont) 



D0 WN HORIZONTAL 

DUPLEX ICTDELAY 

DYNAMIC H>LE 

EBCDIC IF 

ELSE ILLEGALCHR 

ENABLED INCREMENT 

ENABLEINPUT INHIBITS YNC (SYNCS) 

END INITIALIZE 

ENDOFBUFFER INITIATE 

ENDOFNUMBER INPUT 

EQ (EQL) IR 

EQL (EQ) LD (LINEDELETE) 

ERROR LE (LEQ) 

EVEN LEQ (LE) 

EXCHANGE LINE 

FALSE LINEDELETE (LD) 

FAMILY LINEFEED 

FETCH LOGICALACK 

FILE LOGIN 

FINISH LOSSOFCARRIER 

FOR LS (LSS) 

FORK LSS (LS) 

FORMAT MAXINPUT 

FORMATERR MAXSTATIONS 

FREQUENCY MCS 

GE (GEQ) MEMORY 

GEQ (GE) MICRO 

GETSPACE MILLI 

GO MIN 

GT (GTR) . MODE 

GTR (GT) MODEM 

HOME MSGSPACE 



RESERVED WORDS (Cont) 



MYUSE 


SHIFT 


NAKFLAG 


SKIP 


NAKONSELECT 


SKIPCONTROL 


NE (NEQ) 


SPACE 


NEQ (NE) 


SPO 


NOINPUT 


STANDARD 


NOISEDELAY 


STATION 


NORMAL 


STOPBIT 


NOSPACE 


STORE 


NOT 


SUM 


NULL 


SYNCS 


ODD 


TAB 


OUTPUT 


TALLY 


PAGE 


TASK 


PAPERMOTION 


TERMINAL 


PARITY 


TERMINATE 


PASSIVE 


TEXT 


PAUSE 


THEN 


PHONE 


TIMELIMIT 


PTTC6I 


TIMEOUT 


QUEUED 


TO 


READY 


TOG 


RECEIVE 


TOGS 


REMOTE 


TRAN 


REQUEST 


TRANERR 


RETRY 


TRANSLATETABLE 


RETURN 


TRANSLATOR 


SCREEN 


TRANSMISSION 


SEC 


TRANSMIT 


SECURITY 


TRANSMITDELAY 


SEQERR 


TRUE 


SEQUENCE 


TURNAROUND 



( INHIBITS YNC) 



RESERVED WORDS (Cont) 

TYPE WIDTH 

UP WRAPAROUND 

USER WRU 

VALID WRUFLAG 
WAIT 
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APPENDIX B. TRANSMISSION CODES 



BAUDOT CODE 








1 o 


1 


1 






1 


I 

1 












bk 
\ 

f 


1 

f 


1 


K 1 
D 1 

f 


"s^Co 1 umn 
Row f^s^ 





1 


2 

Mm 


\ 
J 

















BLK 


T 


BLK 


5 











1 


1 


E 


Z 


3 


It 








1 





2 


LF 


L 


LF 










1 


1 


3 


A 


W 




2 

4m 





1 










SPACE 


H 


SPACE 


DIAMOND 


o 


1 





1 


5 


S 


Y 


BELL 


6 





] 


1 





6 


1 


P 


8 





o 


1 


1 


1 


7 


U 


Q 


7 


1 


1 











8 


CR 





CR 


9 


1 








1 


9 


D 


B 


$ 




1 





I 





10(A) 


R 


G 


k 


& 


1 





1 


1 


1KB) 


J 


FIGS 


1 


FIGS 


1 


1 








12(C) 


N 


M 




• 


] 


! 





1 


13(D) 


F 


X 




/ 


1 


1 


1 





14(E) 


C 


V 




3^-<" 


1 


1 


1 

L 


1 


15(F) 


K 


LTRS 




LTRS 
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DATA REPRESENTATION 



EBCDIC BCL EBCDIC DECIMAL EBCDIC 

GRAPHIC GRAPHIC HEX. INTERNAL VALUE CARD CODE 



BCL BCL BCL USASCII 

OCTAL INTERNAL EXTERNAL CARD CODE X3.4-1967 



DianK 




Ad 
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1 . EBCDIC 1 00 11 1 also translates to BCL 111010. 

2. EBCDIC 1 100 1 1 1 1 is translated to BCL 00 0000 with an 
additional flag bit on the most-significant bit line (8th bit). This 
function is used by the unbuffered printer to stop scanning. 

3. EBCDIC 1110 0000 is translated to BCL 00 0000 with an addi- 
tional flag bit on the next to most significant bit line (8th bit). 
As the print drums have 64 graphics and spaces, this signal can be 
used to print the 64th graphic. The 64th graphic is a "CR" for 
BCL drums and a for EBCDIC drums. 



BCL 
INTERNAL 

00 0101 
00 0110 
00 0111 
00 1000 
00 1001 



BCL 
EXTERNAL 

00 0101 
00 0110 
00 0111 
00 1000 
00 1001 



BCL 
CARD CODE 

5 
6 
7 
8 
9 



USASCII 

X3.4-1967 

011 0101 
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4. The remaining 189 EBCDIC codes are translated to BCL 
00 0000 (?code). 

5. The EBCDIC graphics and BCL graphics are the same except as 
follows: 
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APPENDIX C, SOURCE INPUT FORMAT AND CODING FORM 

SOURCE INPUT FORMAT . 
An NDL source prognu,, is repute- by a se, 

come from cards, tape, disk remote dev.ee "'^'"^Sons 1^72 are assumed to contain elements 
given record must be divided into two area.. *»W*J^ 6 of this manual) for compilation by 
ff the Network Deflnition ^^^^^^^X^Mom^« t ^^^ 

Thereisno fixed formatforsour^ 

appear in a free format form, vflth the foBowmg S^^ t "J™ mttalei from record to the next. For 
CODING FORM . _ . . 



CODING FORM 
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APPENDIX D. COMPILE-TIME OPTIONS 



COMPILER CONTROL STATEMENTS 

The user is provided with the compile-time ability to control the manner in which the compiler processes 
the source input that it accepts. The user can specify the manner in which the compiler is to receive the 
source input, the consequences of certain syntax errors, and the form of the generated compiler output. 
The compiler control statement is the medium by which these constraints are communicated to the 
compiler. Such statements are entered into the compiler by cards in the same manner as source language 
statements. Compiler control statements, entered as input to the compiler via option control cards, can 
occur at any point in the compiler input files and must contain only compiler control information. 

An option control card is identified by the appearance of a dollar sign ($) in the first or second column of 
the card. If the $ is placed in card column 2, the option control card image is placed in the updated 
symbolic file (NEWTAPE) if such a file is generated. Compilation control information is punched in the 
succeeding columns through column 72, with an eight-digit sequence number in columns 73 through 80. 
All blanks in columns 73 through 80 represent the lowest-value sequence number. An option control card 
with no other compiler information causes the card image in the secondary input file that has the same 
sequence number to be ignored. 

The basic element of compiler control information is the compiler option, which can be invoked by the 
appearance of its name on an option control card. Two mutually exclusive states are associated with the 
majority of these options: SET and RESET; various compiler functions are dependent upon the states of 
such options. Default states are assigned to these compiler options, and the desired state of such an option 
can be specified on an option control card. Such option control cards can also contain arguments associated 
with the option. The balance of compiler options are parameter options with which no states are associated. 
The functions performed by these latter options are initiated by the appearance on an option control card 
of the appropriate option name and any related arguments. 



OPTION CONTROL CARDS 



Syntax 




D-2 



Semantics 



The purpose of a compiler control statement is the assignment of a desired value or state (SET or RESET) 
to an indicated compiler option(s). Such a control statement must begin with either an explicit or an 
implicit option action. An explicit option action is defined as one of the following mnemonics: SET, 
RESET, or POP. 

An implicit option action is indicated when a compiler control statement contains only the names of 
options and no explicit option action. In the latter case, all options named in the compiler control state- 
ment are assigned the state SET, and all other options are assigned the state RESET. 

If a compiler control statement begins with the option action SET, the options following the option action 
are assigned the state SET; the states of all other options are unchanged. If the compiler control statement 
begins with the option action RESET, the options following the option action are assigned the state RESET; 
the states of all other options are unchanged. If the specified option action is POP, then the options Have 
not been changed previously from their default states. The states of all other options are unchanged. The 
following statements are examples of compiler control statements employing the SET, RESET, and POP 
option actions. 

$ SET LIST SINGLE 
$ RESET VOID 
$ POPNEWNEWSEQERR 
$ SET SEQ 0+100 

An option that has a default state of RESET is initially assigned a 48-bit stack word filled with zeros; an 
option that has a default state of SET is initially assigned a 48-bit stack word with a 1 on top and zeros in 
the remaining positions. The top stack position denotes the state of the option at any time. Each SET 
option action causes the stacks allocated to the designated standard options to be pushed down one bit 
and a 1 to be placed at the top of each of these stacks. Each RESET causes the appropriate option stacks 
to be pushed down one bit and a to be placed at the tops of these stacks. POP causes the stacks corre- 
ponding to the designated options to be POPped up one bit, causing the associated options to revert to 
their immediate previous states. Since the size of these option stacks is 48 bits, a maximum history of 48 
states can be recorded. When an option control card appears that has a standard option name and an 
implicit option action, the resultant action is identical to that which would have reseulted had all 48 bits of 
each standard option stack been RESET and followed by an explicit SET performed on each indicated 
option. For example, after the appearance of an option control card containing: 

$ SINGLE 

the history stack for the SINGLE option contains a 1 in the top stack position and all zeros in the following 
positions. The history stack for each of the other compiler options would then contain all zeros. A com- 
piler control statement that applies to compiler options begins with an explicit or implicit option action 
and contains a list of options to which the option action is to apply. This statement ends when the next 
implicit option action is encountered on the compiler control card or when a percent sign is encountered 
on the compiler control card or when a percent sign is encountered or column 72 of the card is reached. 
The compiler options affected by the compiler control card retain the indicated states for all input cards 
with sequence numbers greater than the sequence number on the compiler control card that has the 
control statement, or the physically succeeding input cards for a deck in which all sequence numbers are 
blank, until another compiler control card is encountered that alters the option states. The following 
illustration (figure D-l) is an example of a card that has compiler control statements employing option 
actions: 



/ $ SET SINGLE LIST SEQ 10 + 5 RESET SEQERR 



00001070 



Figure D-l . Option Control Card 



The option control card assigns the state SET to the options SINGLE, LIST, and SEQ, with the sequencing 
arguments of 1 and +5. It also assigns the state RESET to the option SEQERR. The card has the 
sequence number 00001070 in columns 73 through 80. 

OPTIONS 

The compiler recognizes the following identifiers as valid compiler option names: . 



The compiler options are discussed alphabetically in the following paragraphs. The default state of each 
option is indicated in parentheses following the option name; the function performed by the option is 
discussed in the paragraph accompanying the same. 

If an option control card is empty, it has no effect on other options; however, if there is a card image on 
the symbolic tile with the same sequence number as the empty option control card, the image on the 
symbolic file is deleted. 

The compiler options are as follows: 

CODE ( RESET) 

The code option causes the printout to contain the compiler-generated object code. 
DCPLIST (RESET) 

If SET, lists code addresses of each source statement on the LINE file. (There will be two separate lists 
addresses if used for two DCPs, three for three DCPs, etc.) 

DUMP (RESET) 

If SET, causes a "raw dump" listing of NIF on the LINE file. 



CODE 
DCPLIST 
DUMP 
ERR LIST 



NOWARN 

PAGE 

SEQ 

SEQERR 

SINGLE 

SUMMARY 

SYNTAX 

VERSION 

VOID 

yOIDT 

$ 



LIMIT 
LIST 
LISTP 
MERGE 



NDLMACRO 
NEW 

NEWSEQERR 
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ERR LIST (RESET) coonRFll F file 

■ i- fArf-ANinF ti> be- written on the ERROKMi*fc nic. 

il,e ERRLIST option causes syntax error mlormat o n ^«^^^^ ritten in the ERRORFILE 
When a compilation error is detected m *e «ou«ei^ ^omo^iSed S>m a remote terminal by the 
file. This option is provided primarily fm ^^^^.^ the compiler is called. When the 

automatically equated to the remote device mvolved. 
LIMIT (cannot be SET or RESET) 

The imeser parage, aUows .he user <o co.ro, complier error —on, The proper forma, for .he 
LIMIT option is as follows: 



LIMIT (integer) . \ 

If no LIMIT statement appears, a default error limit ot 1 M> is assigns 
through CANDE, in which case the default error is 1U. 

LIST (SET; RESET for CANDE) _ 
L1STP (RESET) 

When SET, .he USTP **» JS***?^ E^^-S^V* 

included on the printout * e ™*f™^ SfesnX state of LISTP is ignored. Therefore, 

M^RGE compUer option ^f^tf^^^t^ 

numbers that can be found on cards in the CARD file. 
NDLMACRO (RESET) 

If SET, the NDL MACRO interface code will be printed following each statement within a (revest 
definition) or (control definition) . 



wTn't^ 

the updated symbolic output file NEWTAPE. This t ft compiler through the TAPE 
records and 450-word blocks. P*"** on the NEWTAPE file 

file. All option control cards >n the l^J^^^j^Zd column 2. 
when NEW is SET and only if the initial $ sign on these cards is m ca 

u cct ™a pfsft as necessary by option control cards appearing at any PO"J^ n 
^inpm 2? ^op. r»Sr^« « «»e NEWTAPE fiie i, *e S s lg ns on .hese 

cards are in column 2. 



The NEWTAPE file is created despite the occurrence of syntax errors in the source input. This file can be 
used as a secondary input for a later compilation. 

The NEWTAPE file can be label-equated so that, for example, the output goes to magnetic tape. 
NEWSEQERR (RESET) 

The NEWSEQERR option causes sequence errors on the NEWTAPE file to be flagged. If sequence errors 
occur and the NEWSEQERR option is SET, the NEWTAPE file is not locked, and the message NEWTAPE 
NOT LOCKED {number of errors] NEWTAPE SEQUENCE ERRORS is printed on the printout. 
NEWTAPE, N IF, and DCPCODE files are not locked. 

NOWARN (RESET) 

When SET, suppresses any compiler warnings from appearing on the LINE file. 
PAGE (cannot be SET or RESET) 

The PAGE compiler option must appear on a option card without an option action preceding it. When a 
PAGE option card appears, the printout is spaced to the top of the next page, but only if the LIST option 
is SET. 

SEQ (RESET) 

The proper format of the SEQ option is as follows: 

SEQ (base) + (increment) 

If the SEQ option is SET, the printout and the new secondary source language file, NEWTAPE, contain 
new sequence numbers as defined by the (base) and (increment) . If the (base) and (increment) are 
unspecified, a base of and increment of 10 are assumed. 

This option has effect only when the LIST and/or NEW options are also SET. The sequence numbers that 
appear on the card images in these files when the SEQ option is RESET are identical to the sequence 
numbers on the corresponding cards in the input file. 

Example 

/% SEQ 100 + 100 ; ~ 00005000 



This compiler control card specifies that, when the state of the SEQ option is SET, sequencing begins with 
the sequence number 00000100 and proceeds in increments of 100. 

SEQERR (RESET) 

The SEQERR option causes sequence errors on the TAPE file to be flagged. If sequence errors occur and 
the SEQERR option is SET, DCPCODE and NIF files are not locked, and the message CODE FILE NOT 
LOCKED J number of errors} TAPE SEQUENCE ERRORS is printed on the printout. 



SINGLE (RESET) 



The SINGLE option causes the printout to be single-spaced. When the SINGLE option is RESET, the 
printout is double-spaced. (Note that double-spacing is default.) 

SUMMARY (RESET) 

If SET, lists on the LINE file the memory space allocations for user translation tables and terminal 
message space allocations for each DCP. 

SYNTAX (RESET) 

When SET, the source program is checked for syntax errors only. DCPCODE and NIF files are not 
generated. 

VERSION (SET, RESET, and POP are ignored by the compiler) 

The VERSION compiler option allows the user to specify an initial version number for a source program, 
to replace an existing version number, or to append an existing version number. 

Examples 

$ VERSION 25.010.010 
$ VERSION +01. +001. 010 

When compiling with the NEW compiler option SET and a VERSION compiler card appears in the symbolic, 
and if the patch deck contains a VERSION compiler option, the new symbolic is updated to the version, 
cycle, and patch number on the last VERSION compiler card in the patch deck. The sequence number 
must be less than the one in the symbolic. 

VOID (RESET) 

If the VOID option is SET, all input, other than $ cards, from the TAPE and the CARD files is ignored by 
the compiler until the VOID option is RESET or POPped into a RESET state. The ignored input is 
neither listed nor included in the updated symbolic file regardless of the states of the LIST and NEW 
options. The VOID option can be RESET, once it is SET, only by a option control card in the CARD file. 

VOIDT (RESET) 

If the VOIDT option is SET, all secondary input, other than $ cards, from the TAPE file is ignored by the 
compiler until the VOIDT option is RESET or POPped into a RESET state. Therefore, while the VOIDT 
option is SET, only primary input is compiled. The ignored input is neither listed nor included in the 
updated symbolic file regardless of the states of the LIST and NEW options. The VOID option can be 
RESET, once it is SET, only by an option control card in the CARD file. 

$ (RESET) 

When SET, the dollar sign ($) option causes the printout of all subsequent (option control card) images 
when the LIST option is SET. This option appears as SSETS or $ $. 
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APPENDIX E. COMPILER SOURCE AND OBJECT FILES 



COMPILER FILES 

Compiler communication is handled through various input and output files (figure E-1). Cards, disk, or 
magnetic tape can be specified as source language input media. Input must be in the input format defined 
in the preceding sections. The compiler has the capability of merging, on the basis of sequence numbers 
input from cards, tape, or disk. When inputs are being merged, indications of text insertions or replace- 
ments can be made to appear on the printout. In addition to the printout, the compiler can also generate 
updated symbolic files. These files can be created in addition to the compiler-generated output code file. 

Input Files 

The primary compiler input file is a card file with the internal name CARD; the secondary input file is a 
serial disk file with the internal name TAPE. The presence of the primary file (CARD) is required for each 
compilation; the presence of the secondary file (TAPE) is optional for each compilation. When two card 
images, one from the CARD file and the other the TAPE file have the same sequence number, the former 
is primary and is compiled, and the latter is ignored. This is the standard mode of handling source language 
mput. File CARD can be either BCL-coded with 1 0-word records or EBCDIC-coded with 14-word records 
and can be either blocked or unblocked. File TAPE can be BCL-coded with 10-word records and 150-word 
blocks, or EBCDIC-coded with a 14- or 1 5-word record and 420- or 450-word blocks. Both the CARD file 
and the TAPE file can be label-equated (via the FILE system control card) to change the TITLE and 
KIND of the file. The TAPE file is used as input only when the MERGE compiler option is SET. 
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Figure E-l. NDL Compilation System 



Output Files 



Output files produced by the compiler consist of the DCP code file, the Network Information File, an 
updated symbolic file, a line printer printout, and an error message file. The DCP code file has the internal 
name DCPCODE and is saved on disk after the compilation unless the COMPILE system control card 
specifies compilation for syntax only, or unless syntax errors are detected in the source language input by 
the compiler. If compilation for library is specified, then the DCPCODE and NIF files are saved on disk. 
The title of the saved DCP code file is identical to the program name (identifier) appearing on the 
COMPILE system control card with the suffix of /DCPCODE. 

The title of the saved Network Information File is identical to the program name identifier) appearing on 
the COMPILE system control card with the suffix of /NIF. 

The updated symbolic file is, by default, a disk file generated only if the compiler option NEW is SET. 
This file contains the compilation source input or a selected portion of this input as specified by the state 
of the NEW compiler option. It can be used as the TAPE file for a succeeding compilation. This output 
file has the internal file name NEWTAPE and contains EBCDIC-coded 15-word records in 450-word 
blocks. 



The line printer printout is an optional print file that is created unless the compiler option LIST is 
RESET. (The LIST option is SET by default unless the compilation is initiated through CANDE.) The 
file has the internal name LINE, consists of 22-word EBCDIC-coded records, and contains the following 
information: 

Source and compiler control statements used as input to the compiler. 
Error messages and error count. 
Number of input card images scanned. 
Elapsed compilation time. 
Processing time required for compilation. 
Total number of words of DCP code generated. 
Number of disk segments required for the DCP code file. 
Title of the generated code file. 

Depending upon the specified setting of the LIST and CODE compiler options, the line printer printout 
can contain more (or less) information than the basic items listed above. Card images from the CARD file 
are denoted on the printout by a C after the card contents. Card images from the TAPE file are denoted by 
a T in this location. A P denotes a patch of a TAPE card image. 

The output error-message file with the internal file name and assigned title of ERRORFILE is an optional 
line printer file that is created when the ERRLIST compiler option is SET. This file is normally employed 
for compilations initiated through CANDE, in which case ERRLIST is SET by default and the ERROR- 
FILE file is assigned to the remote device involved. The ERRORFILE file can also be used for compila- 
tions initiated through the card reader. This file is assigned EBCDIC-coded 12-word records that result in a 
line width of 72 characters, allowing the file to be used as output to a remote terminal or card punch 
without truncation of text. When a syntax error is detected, an error message is written following the line 
of text. The error message consists of an explanatory message and indicates the probable cause of the 
error. 

Compiler File Table 

Table E-l, NDL Compiler Files, lists the external name of the file (i.e., the name one would label-equate to), 
the internal name of the file (i.e., the name used when the file is declared within the compiler), the 
purpose served by the file, the default KIND of the file, the code used to store file data, the default record 
size (M AXRECSIZE) and block size (BLOCKSIZE) of the file, and a brief commentary on the specific 
file. The attributes of any of these files can be changed by the use of FILE system control cards directed to 
the compiler. 



Table E-l . NDL Compiler Files 



EXTERNAL NAME 



INTERNAL 
NAME PURPOSE 



KIND 



RECORD 
CODE 1 SIZE 



BLOCK 
SIZE 



COMMENTS 



NDLSOURCE 



CARD 



Input Card 
File 



CARD 
READER 



EBCDIC 



BCL 



14 Words 



10 Words 



Blocked 
or 

Unblocked 



SYMBOL/SOURCENDL! TAPE Input Disk 

File 



DISK 



</dewri/?er>/DCPCODE 




DCPCODE 



EBCDIC 



BCL 



j 14 or 15 
j Words 

i 

I 10 Words 



420 or 450 
Words 

150 Words 



Required for each compilation. Primary 
compiler input file; may be label- 
equated to change file attributes. 
CANDE file is equated to this file auto- 
matically for compilations initiated 
through CANDE. Default title is 
NDLSOURCE. 
BUFFERS = 2. 
FILETYPE = 8. 

Optional file; need not be present for 
each compilation. Secondary compiler 
input file; selected as input by SETting 
MERGE compiler option. Can be label- 
equated to change file attributes as 
desired. The default title is 
SYMBOL/SOURCENDL. 
FILETYPE = 8. •• 

Generated DCP code file. Saved or dis- 
carded and assigned a title as indicated 
by compilation method. For CANDE 
compilations, the title becomes: 
OBJECT/<Wenri/ier>/DCPCODE : 



SYMBOL/SOURCENDL NEWTAPE 



Updated 
Symbolic 
Output 
File 



DISK 



EBCDIC 



15 Words 



450 Words 



Optional output file produced when 
NEW compiler option is SET. This file 
contains portions of the source input 
and is label-equatable. It is suitable for 
use as a TAPE file for a later 
compilation. 
BUFFERS '* 2. 
AREASIZE = IQfXK 
AREAS =20. 
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EXTERNAL NAME 


INTERNAL 
NAME 


PURPOSE 


KIND 


CODE 


RECORD 
SIZE 


BLOCK 
SIZE 


COMMENTS 


(identifier}/MF 


NIF 


Network 

Information 

File 


DISK 




30 Words 


420 Words 


Generated Network Information 
File XNIF). Saved or discarded and 
assigned a title as indicated by compila- 
iion meinou. ror waini/h compilations 
the title becomes: 
OBSECT/(identifier)fNIF. 


UNE 


LINE 


Line Printer 
Printout 


LINE 
PRINTER 
or REMOTE 


EBCDIC 


22 Words 


22 Words 


Optional and label-equatable file. 
Produced when the compiler option 
LIST is SET. 


ERRORFILE 


ERROR- 
FILE 


Error 
Listing 
Output 
File 


LINE 
PRINTER 


EBCDIC 


12 Words 


12 Words 


Optional error listing file produced 
when ERRLIST compiler is SET. 
Contains card images and error mes- 
sages. Automatically provided for 
CANDE input. 
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